[systemd-devel] Utility for persistent alternative driver binding

[Panu Matilainen]

On 12/09/2015 04:26 PM, Greg KH wrote:
> 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".

Um, this is not about renaming, never was.

driverctl is for overriding the default device driver binding. For 
example, to bind a certain device to vfio-pci instead of its dedicated 
driver from the go. Or to use an alternative dedicated driver. Or 
prevent any driver from being bound to a device.

At that early stage there is very little to go with besides the PCI slot 
number and ID.

	- Panu -