>>> [...compatability...]  In this case, a sure way to get the unit ID
>>> without having to guess/devine it from if_xname[] array.

>> Why do you want a unit number?  I can't see why you should care
>> about the difference between, say, "le0" and "rk0" versus "le0" and
>> "le1"; le0 and le1 are just as much different interfaces as le0 and
>> rk0, and there's no call to treat the two cases any differently.

> If I have a group of "struct ifnet"'s that have the same "if_name"
> but different "if_unit", then I might assume they're somehow related.

Indeed you might.  What does "somehow related" buy you?  How can
guessing that two interfaces are or are not "somehow related" be of the
slightest use, even for an LKM?

> If I have a group of "struct ifnet"'s and the only identifier is
> "if_xname", then any hints I might use to construct an idea of
> related network devices inside the kernel are (at best) guesses.

Right.  That's all you have in any case, guesses.  What use can you
make of the guess that le0 and le1 happen to use the same driver, or
that le0 and rk0 don't?  I can't see anything at all it buys
you...except increased code complexity.

> 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).

How?  Only kmem readers will ever see the difference, since all the
"official" interfaces (mostly meaning anything using struct ifreq) use
the interface name as an opaque string already.  And portability is a
weak notion at best when applied to kmem grovelers; I for one really
don't care about breaking external kmem groveler programs - kernel
internal data structures have never been an advertised interface.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu