Ignatios,

> Calm down a bit, both (at least) of you.

Matt Thomas and I have known each other for ~10 years now. While we
havn't always agreed with each other we've always had a solid mutual
respect for one another. So, no need to chastise...

> oldbsdether.h
> 
> with appropriate 
> 
> - #includes to get the right files
> - #defines to backwards translate old calls
> 
> protected by #ifdef __NetBSD__, for the time being.
> 
> So your effort would be reduced to include that file... at the cost of
> reduced reliability of type checking, due to the type casts.
> 
> The only real problem is that there isn't any struct arpcom anymore,
> and people writing the linklevel address directly to it, or reading it
> from there, will fail horribly.
> 
> This shouldn't affect non-Ethernet-style device writers, as they won't
> be able to really work with a 6-byte linklevel address, anyway...

I think it's a mistake to wipe out the old data structures and change
the directory hierachy for the reasons I pointed out in my earlier mail.
You can't change ~15 years of broken history in all 4.*BSD derivatives
by making a localized decision in NetBSD. I think a datalink-independent
architecture makes alot of sense, but not at the expense of backwards
compatibility. I'm certain that both goals can be acommodated by making
changes to the existing data structures, rather than doing away with them
completely. Please consider the suggestions from my earlier message 
(included below) for a method to accomplish this: 

Regards,

Fred
templin@nas.nasa.gov

---cut here---
> Return-Path: templin 
> Received: (from templin@localhost)
> 	by osprey.nas.nasa.gov (8.8.3/NAS.6.1) id PAA15051; Fri, 18 Apr 1997 15:23:10 -0700 (PDT)
> Date: Fri, 18 Apr 1997 15:23:10 -0700 (PDT)
> From: templin (Fred L. Templin)
> Message-Id: <199704182223.PAA15051@osprey.nas.nasa.gov>
> To: ignatios@cs.uni.bonn.de, is@netbsd.org
> Subject: your recent ARP changes...
> Cc: templin, thorpej, kml, tech-net@netbsd.org
> 
> Hello Ignatios,
> 
> My name is Fred Templin, and I work with Jason Thorpe at the NASA
> Ames Research Center. I've been porting a HIPPI network device driver
> suite (kernel-level driver plus supporting app's) to "netbsd-current"
> and was chugging along just fine 'till your ARP changes hit the pool.
> Then (obviously) my build broke and I was suprised to learn that both
> "netinet/if_ether.h" was moved into "net" and the "arpcom" data structure
> has disappeared from the source tree alltogether. From speaking with Jason,
> I think I understand your motivations for the changes that went in and 
> it seems to me like your goals included creating a cleaner architecture;
> which is good. But, I'm afraid you may be setting yourself (and NetBSD)
> up for a long-term source code porting nightmare that won't go away
> anytime soon.
> 
> Very basically, all OS's derived from 4.*BSD have had the arpcom and
> ether_header data structures married together in the "netinet/if_ether.h"
> module since the beginning of time. When new datalinks like FDDI started
> popping up which included similar (IEEE 802-style) MAC headers to Ethernet,
> folks leveraged off the existing modules and data structures rather than
> architecting a datalink-independent solution. Now, I'm not saying that
> this was a good thing - in fact, I'll agree that "if_ether.h" should
> have lived in the "net" directory and the ARP-related data structures
> moved into a different module from the very beginning. But the fact is
> that the other 4.*BSD-derived OS's have maintained the original module
> names and data structures, and changing this in NetBSD now - while
> architecturally clean - is only going to make NetBSD appear to be broken
> in relation to the other OS's.
> 
> By way of example, in my case I'm working with a source distribution
> from Essential Communications which includes a network driver suite and
> supporting applications for a HIPPI/PCI card. Because the Essential guys
> took a kitchen-sink approach to their development effort, their source
> distribution includes approx. 100K lines of code - much of which deals
> directly with the datalink-related  data structures. The driver supports
> Digital UNIX, three different versions of SGI IRIX, HP-UX, and AIX, while
> the supporting applications support all of the above plus WIN95 and NT.
> And, in all of these supported OS's (except the Microsoft OS's, that is),
> the "if_ether.h" module is included as "<netinet/if_ether.h>" and the 
> "arpcom" structure is used as the handle by which the driver finds the
> "ifnet" struct. For me to change that for the NetBSD port now would cause
> me to add hundreds of lines of the form:
> 
>   #if defined(__NetBSD__)
>   struct ifnet *ifp = (struct ifnet *)&(sc->is_ec.ec_if);
>   #else /* defined(__NetBSD__) */
>   struct ifnet *ifp = (struct ifnet *)&(sc->is_ac.ac_if);
>   #endif /* defined(__NetBSD__) */
> 
> in the kernel code. This isn't as bad as the fact that a large number
> of the supporting applications also include "<netinet/if_ether.h>", and
> heaven knows what data structures they once accessed from that module
> which will no longer be available to them. (Not to mention that the
> module has been moved to a new directory!)
> 
> In any event, my main point in this is that I don't see any problem
> with your architectural change to separate ARP out from the specific
> datalink headers. But, I would strongly advocate a "backwards-
> compatibility" approach, in which the traditional directory hierarchy
> and data structure names are preserved. For example, I would recommend:
> 
> 	1) leave "if_ether.h" under "netinet"
> 	2) add comments like crazy to the effect of:
> 
> 	  "THIS FILE IS HERE FOR COMPATIBILITY PURPOSES *ONLY*"
> 
> 	3) create a new module called something like "net/if_enet.h",
> 	   and move the Ethernet-related data strucutures there
> 	4) change the old data structures in if_ether.h (such as arpcom)
> 	   to include opaque pointers to generic underlying datalink
> 	   objects, which are defined in the new modules you've added
> 	   such as "net/if_arc.h", "net/if_atm.h", etc.
> 
> In this way, application and kernel code portability will be preserved,
> folks will know by reading the comments in "netinet/if_ether.h" that
> you've cleaned up the architecture w/o breaking backwards compatibility,
> and NetBSD will be perceived as being ahead of the game w.r.t. the other
> OS's by those in the know.
> 
> Thankyou for your time,
> 
> Fred
> templin@nas.nasa.gov