>>> 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 ..."
>> what does it matter what the interface is called ?
> 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.

Oh, the "somehow related" is useful to a _human_, sure.  But what
difference does it make to a _program_?  Remember, we started off
talking about a kernel module identifying interfaces.  I could, barely,
understand a user-land program trying to be smart and displaying all
the interfaces on that quad ethernet board together.  But that it can
do perfectly well by comparing the string names, which is all it has to
work with anyway.  In the kernel, no, I can't see anything caring.

> 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 ?

This change - if_name/if_unit to if_xname - is completely invisible
except to kernel modules and kmem grovelers.  All the advertised
interfaces (SIOC[SG]IF*, mostly) still continue to take the same string
names they always have.  The only user-land code that this could break
is code that deliberately goes under the hood via /dev/kmem, and I
really feel little pity for it - such code is either doing something
heavily kernel-specific anyway or it's being gratuitously ill-behaved.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu