[systemd-devel] Utility for persistent alternative driver binding
Panu Matilainen
pmatilai at redhat.com
Tue Dec 8 22:43:05 PST 2015
On 12/08/2015 01:47 PM, Greg KH wrote:
> On Tue, Dec 08, 2015 at 11:34:36AM +0200, Panu Matilainen wrote:
>>> As was mentioned recently PCI bus numbers may change between reboots, so
>>
>> Hmm, got a pointer? I dont think PCI slots change between reboots without
>> physically swapping hardware, the "ethX-problem" comes from the order of
>> device discovery being unstable across boots, which is a different issue and
>> not relevant for this case.
>
> PCI can renumber the bus ids any time it wants to between reboots, it's
> not only if you add/remove new hardware. Now luckily most BIOSes aren't
> that broken and do keep keep things stable if the hardware doesn't
> change, but not all do, so be careful about this. I had a broken BIOS
> that would renumber things about every 10 reboots just "for fun" that
> was very good at using for testing system assumptions about static PCI
> device ids.
Ugh :-/ I've clearly only seen well-behaved BIOSes. But even if the news
is bad its good to know, thanks.
>
>>> you may want to start with something more stable from the very beginning.
>>
>> Such as? I dont see any other data that is there for all PCI (and USB)
>> devices that allows differentiating between two otherwise identical devices.
>
> Again, it all depends on the device itself, they should provide
> something that makes them unique (MAC address, serial number, topology
> at the moment, etc.) There is no one-thing-fits-all, which is why udev
> provides so many different ways to name things (look at /dev/disk/* and
> /dev/serial/* as examples of this.)
At the time driverctl runs, things like MAC address are not available
since the normal driver is not loaded, its just a "raw" device on a bus.
So I guess it'll need to grow an alternative mode that allows override
by PCI ID and operates on all devices by that ID, which loses a bit of
control vs the slot number but for the cases where slot number isn't
reliable...
- Panu -
> good luck!
>
> greg k-h
>
More information about the systemd-devel
mailing list