Burakov, Anatoly, Aug 20, 2024 at 11:40:
I have heard about driverctl for a long time in context of devbind, and
I quickly tried it out just now, and IMO while the *functionality* is
there, the usability of devbind is IMO far more friendly:
- it filters by device types that are of interest to us (driverctl just
lists all pci devices)
- it prints out user-friendly names, not just PCI addresses
- it lists loaded drivers, but not alternatives etc. like devbind does
- I didn't test this, but I suspect it would allow overriding driver for
an active NIC
- after my changes, devbind displays NUMA socket, driverctl doesn't :)
Yes, that's fair. devbind is more a dev oriented tool. driverctl is
really focused on reproducible and persistent driver override (it has
a systemd service that will force a rebind of pci devices on reboot).
What we maybe can do for e.g. next release (currently I do have better
things to do if I can help it), is to make devbind a wrapper around
driverctl? This way, we can still keep the usability bells and whistles
we have, but drop the driver overriding code and leave it to driverctl?
It seems like that would be a good compromise, with the only downside
being that we'll depend on driverctl being installed.
Honestly, I don't think the dependency would be a good idea. Also,
driverctl does not have any option to make a driver override temporary.
It will persist after reboot which is not what devbind does.
