Date:        Sun, 4 Nov 2001 00:20:59 -0500
    From:        Mike Pelley <mike@pelley.com>
    Message-ID:  <20011104002059.A16718@pelley.com>

  | It would be disconcerting to have higher numbered interfaces slide down
  | when a card is removed (although this parallels hard drives).  Often
  | replacing a defective ethernet card is time-critical, whereas removing
  | an ethernet card rarely is.  I would rather see the shell access
  | required for the less urgent situations.

On most of the bus types supported by NetBSD (even if they are the older
and today less used ones - ISA, VME, Multibus (is that supported?), unibus,
(etc)) there's not any guarantee anyway.

On the newer busses (those with self identifying devices and automatic
location mechanisms, PCI, sbus I think, ...) it would be possible to make
it work, but only on those.

On the older busses, the only way to guarantee any particular numbering
is either to want the one that is currently found, and change nothing at
all (at least, no noticeable changes), or wire down the specific configuration
(the ethernet at address X is to be called number 3).

The latter makes it even harder to change hardware - you need to config
and boot a new kernel, so you're obviously not going to want that.  That
leaves change nothing - and that with either naming scheme preserves the
mappings.

The reason for all of this is that on the older busses, the autoconf code
steps through the drivers, one by one, allowing the driver to claim any
hardware it wants.  That is (depending upon the order the kernel actually
uses, I'm guessing here) - it finds all the 3com (ep) ethernets, and then
all the smc (we) ethernets, then all the dec (de) ethernets, ...

So, if you had 3 ep ethernets, and they were called ep0 ep1 and ep2 and
you replaced ep1 with a dec ethenet, what you'd have would be ep0 ep1 and
de0.   On the other hand if they were eth0 eth1 and eth2 then what you'd
have would be eth0 eth1 and eth2 - but the dec one would be eth2 (or maybe
eth0) - it couldn't be eth1, even though it was the card that used to be
eth1 that was replaced.

This makes the ethN scheme actually worse than the epN deN weN scheme, as
you still end up with exactly the same set of names, but they no longer
connect to the same nets - so now your config all works, but after that
nothing else does.  On the other hand, with the current NetBSD (*BSD)
scheme, you find out at config time that things are broken, and it is
obvious what needs to be altered.

On PCI (etc) busses you needn't suffer from this, as the bus will allow
the kernel to find out what is in the slots, one by one, then the driver
can be run to config the slots in order - in a direct replacement scheme
the cards will (or at least could) be configured in slot order, so the
numbering would stay the same.

But there's no free lunch - to get this benefit, the slot position of the
cards becomes critical - if for some physical reason you can't put the
replacement card in the same slot as the card it replaces, then you end
up tossing the dice again as to what order the cards will be found (logical
slot numbering and physical positioning aren't always related).   But with
the current NetBSD scheme, if you have cards with different chips, say a
3com (ex0) and Intel (fxp0) then wherever you plug in the cards they'll
keep the same identity.  With ethN numbering, no guarantees.

There simply is no one right way for this, whatever path is chosen some
things work better, and other things work worse.

kre