> 
> 
>    [ ... ]
>    i.e., in using if_unit & if_name, one might assume that "le" #0 and "le" #1
>    are somehow related.
> 
> who cares if they are related ?  "Maybe I'm Missing Something ..."
>    
>    The implication of "if_xname" is that the number for the interface is
>    not needed to indentify an interface, an interesting concept but is it
>    really that much of a problem that we want to make portability of
>    applications that much harder ?  (any programs like netstat will have to be
>    altered to deal with this, for example).
> 
> hmm?
> 
> what does it matter what the interface is called ?

(I assume you're asking for arguments sake...I'm sure you can understand
 why it is useful.)

Well, if you have an intrface named "joe" and an interface named "bar",
tell me which is connected to your first quad ethernet device and which
is your lance ethernet.  If I connect another to the quad ethernet card
and call that "foo", how do I know this ?

Maybe we should call disk devices "/dev/d1p1" (disk 1, partition 1), etc,
irrespective of it being SCSI or IDE and the kernel autoconfigs them to
have similar names.

Maybe I'm really stupid/strange, but if an interface is called "le0" and
that "le" is related to the driver name "le~ (short for lance), and the
same for others, when I do "ifconfig -a" and see "le0", "qe0", "qe1" and
"ppp0", I at least don't have to think too much about what they refer to.

Whilst the abstraction is nice, I think it is disadvantageous to remove
the meaning from names which currently have meaning.  If the change were
to "lance0" & "lance1", no problem.

If I write software that has to deal with network interfaces, maybe
network management, maybe something else, and I know that an "le" device
is a "lance ethernet" on NetBSD and "ne" is an n2k, then I can make some
useful assumtions that require less effort on user behalf when installing
software.

What about programs which run under SunOS4.1.x and assume a few things
about network names, etc.  Why break compatibility for the sake of
change ?  (Although Jason mentioned that the code is now less complex
and faster, I doubt that the change will have significant impact from
a system perspective for performance).  It just makes the job of those
not in core and who can't sup nightly that much harder and NetBSD less
attractive as a target platform.

Maybe programs that grovel /dev/kmem deserve all they get, but I'd hope
they only have to change when there is worthwhile change.

darren