[systemd-devel] Utility for persistent alternative driver binding

[Greg KH]

On Wed, Dec 09, 2015 at 08:43:05AM +0200, Panu Matilainen wrote:
> 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.

See the other messages in this thread about how Qemu will also give you
semi-random PCI addresses every other boot, that's a much more common
problem and something easy to test with.

> >>>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.

It's a PCI device on the bus, not a network device.  When you create the
network device, then you have a MAC address.  You never need to rename a
PCI device.

> 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...

What?  What are you trying to "rename" here?  I thought we were talking
about network devices, or something else that a user actually interacts
with.  Userspace never deals with a "raw" PCI device, you should never
care about those ids for anything "real".

thanks,

greg k-h