[systemd-devel] when/where was support for assigning "ethX" names removed?

[Chris Friesen]

On 05/27/2016 08:36 AM, Lennart Poettering wrote:
> On Thu, 26.05.16 12:28, Chris Friesen (cbf123 at mail.usask.ca) wrote:
>
>> So I've been playing with this a bit, but I've run into another snag.  It
>> seems that on initial boot even with "net.ifnames=0" the ethernet interface
>> ordering isn't consistent.
>>
>> This means that two systems with identical hardware can end up mapping
>> "eth1000" to different physical slots.  This makes it very difficult to set
>> up multiple machines.
>
> Yupp, thta's what we have been saying all along: enumerating and
> probing devices is not stable, that's why the predictable interface
> names have been introduced after all, so that the same name refers to
> the same device all the time.
>
>> I assume this is due to parallel network device initialization from
>> udev?
>
> Well, udev just modprobes the driver. The driver then probes all
> devices and that happens in any order it likes.

Looking at the kernel code, the probing order for pci NICs for a given driver is 
pretty well deterministic.  From what I can tell, the problems happen when we 
modprobe another driver before the previous one is finished walking the bus. 
When this happens you can get sequential device numbers being assigned to one 
driver, then the other, then back to the first.

>> Is there a way to serialize this at the cost of slower system
>> initialization?  I don't really care what the ordering is, as long as it is
>> consistent on identical hardware.
>>
>> (Yes, I realize that the ideal would be to use the newer position-based
>> naming, but that would mean a whole lot more work at this point.)
>
> Well, the old scheme is borked, that's why we fixed it. You don't like
> the fix, but want it fixed anyway. Not sure what else we can suggest...

The reason why I'm poking at this is that the old scheme worked "good enough" 
for us for several years.  Now of course the new scheme is better, but it breaks 
backwards compatibility.  This makes it difficult to automatically upgrade an 
existing system to an OS using the new scheme since all the names would change. 
  (And we've got the old interfaces stored in databases and such in our 
management software.)

And the annoying thing is that if I turn off the new naming scheme there seems 
to be less determinism than there used to be.  I assume this is due to the 
effort to extract more parallelism at boot, but it's causing me grief.

Anyways, I think I understand enough about what's going on to try and figure out 
a workaround until we can move to the new naming scheme.

Thanks for the help,
Chris