Date:        Fri, 2 Nov 2001 17:14:50 -0600
    From:        Dan Debertin <airboss@nodewarrior.org>
    Message-ID:  <15331.10474.235565.724314@senator.nodewarrior.org>

   | To wit, then, what I want to know is why *BSD is using the underlying
  | hardware as the basis for the names of network interfaces, i.e. xl0,
  | ep0, rtk0, etc. I know there are historical reasons,

That's why, but it goes back further than you may think, way back before
LANs in any relevant form existed.

From way back, most likely the first unix (though that's before even my
time), devices have been identified (in the kenel) by their controller
type, and then a unit number on that controller.   The controller name,
was generally limited to 2 characters (sometimes three) so that it could
be used as a prefix for all the driver's function names, global vars, etc,
even when working with linkers that used only 8 (or even 6) significant
characters of names.

The names exposed to the users in the filesystem (/dev) could have
differed of course, there could have been /dev/disc0a /dev/disc1a ...
but that wasn't done, instead there were /dev/rl0a /dev/rk0a /dev/rp0a.

That both allowed a more obvious connection between the name and the
driver - which was useful for anyone working on the system, but also
made it much easier for the end user (operator) - if you want to put
a disc pack in a rl drive, and you attempt to slot a rp pack in there
you're going to have an interesting time of it...

So, the controller type (hardware type) was exposed to the users from
the very early days.  These days almost all discs are IDE or SCSI, and
many machines have only one of those types, so all the drives tend to
have a similar name (just the number changes) on any particular system,
and there's essentially no demand for changing (on NetBSD) from wd0 wd1
and sd0 sd1 into disc0 disc1 disc2 disc3 (or something - though some
commercial unix variants did move that direction).

When network devices were added, even though they didn't appear in the
filesystem, the "obvious" thing to do was to continue the same approach.
The driver (which is intimately related to the generic hardware type) is
still identified by a short prefix, for the same reasons (though it no
longer has to be so short) - the same name was simply exported to user
space (via a different interface).

  | but it
  | _seems_ better from a usage & automation (scripting) standpoint to
  | have all ethernet interfaces called simply "ethX". Why should userland
  | have to care about what the hardware is?

There is no good reason (the reasons that have been given in replies to
your message are all rubbish).

But nor is there any good reason to change.

What's more, if there was to be a change, it wouldn't be to ethN - why
should userland need to care (99.999% of the time) whether the device is
an ethernet, or fddi, or token ring (I guess there are still a few around)
or wireless, or ...   Or for that matter, one of the variants of tunnel,
or ppp, or ...

If there was to be a change, netN would be the choice, so all network
interfaces could be named the same.

Of course, this would be of very little benefit to anyone - apps (even scripts)
typically want to be able to run on more than one system, and unless you
could convince the whole world (all posix type systems) to change to the
new naming scheme, then all the apps still need to be able to work out what
exists and cope with it.

For the human operators, which naming scheme wins very much depends upon
which set of circumstances you imagine happening, and what you want the
effects to be.   Neither is better all of the time.

The more likely thing to happen incidentally, is that most of these names
will become more and more hidden - instead of using ex0 fxp0 ... the
interfaces are likely to be logical things living on top of those (vlan0
bridge0 ...) and it will be those that most apps will need to deal with.

The same is true of discs of course, with more and more raidN and/or ccdN
existing (even vcdN if that is how encrypted filesystem support is going
to exist).

kre