Simon Hobson <linux@???> writes:
> Nate Bargmann <n0nb@???> wrote:
>> After I thought about it some, there is a certain logic to udev's
>> behavior but it would seem to make more sense if the network adapter is
>> on a hot-pluggable interface (PCMCIA, USB, etc.), or is in addition to
>> the adapter already assigned to eth0 on a PCI bus. The behavior of
>> assigning eth1 to a new adapter on a PCI bus where the old adapter no
>> longer is present
>
> Unfortunately, absent the "admin mind reading" kernel module, I doubt
> this can ever be solved for everyone. For me, the standard udev way of
> doing it works - it's simple enough, and easily enough managed as long
> as you remember to edit the file when you change hardware. I have
> "unfond" memories of working with a box in the past where the
> interfaces came up in seemingly (to inexperienced me) random order
> such that I'd be using eth0 during install, then when I booted the
> installed system I found eth0 didn't work and I should now be using
> eth1 - but if I booted from the CD for maintenance (I learned a lot
> from breaking things !) then they'd swap back again.

udev is based on a single event reader process which distributes actual
work to a number of 'worker processes' running independently of each
other. Because of this, the driver initalisation routines (sitting in
modules) might be called in an order different from the device detection
order, hence, if more than one driver use the same 'device namespace'
(like ethX), assignment of actual Xes to different drivers may vary.

It's pretty easy to fix this:

    - assign a sequence number to each driver load event reflecting
          the device detection order

    - use a module loading program (really a modprobe wrapper)
          utilizing these sequence numbers to work out the order modules
          should be loaded in

The implementation I'm using does this by creating a file whose name is
the sequence number of the driver to load next in a subdirectory of
/dev. Concurrently started driver loaders use dnotify[*] to watch this
directory and 'do their thing' once their sequence number
appears. Afterwards, the instance which finished its work delete its
sequence number file and creates the next one.

[*] Originally, I was using inotify for that but inotify only supports a
    limited number of concurrently open inotify descriptors (the default is
    256) and I'm trying to stay clear of "just use a large enough
    statically allocated table" mechanisms whereever possible. I prefer
    "just implement it correctly, even if that's marginally more work".