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 -
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
