On 12/04/2015 04:41 PM, poma wrote:
On 04.12.2015 15:27, poma wrote:
On 04.12.2015 10:40, Panu Matilainen wrote:
Hi all,
To follow-up on this thread from September-October:
http://lists.freedesktop.org/archives/systemd-devel/2015-September/034427.html
http://lists.freedesktop.org/archives/systemd-devel/2015-October/034551.html
The driverctl utility has matured a bit from the earliest tyre-kicking
version seen there and now lives at laiskiainen.org/git/?p=driverctl.git
Since it has everything to do with udev this seems like a reasonable
forum to advertise it a bit. Quoting from the README a bit:
driverctl is a tool for manipulating and inspecting the system
device driver choices.
Devices are normally assigned to their sole designated kernel driver
by default. However in some situations it may be desireable to
override that default, for example to try an older driver to
work around a regression in a driver or to try an experimental alternative
driver. Another common use-case is pass-through drivers and driver
stubs to allow userspace to drive the device, such as in case of
virtualization.
driverctl integrates with udev to support overriding
driver selection for both cold- and hotplugged devices from the
moment of discovery, but can also change already assigned drivers,
assuming they are not in use by the system. The driver overrides
created by driverctl are persistent across system reboots
by default.
>
Usage
-----
Find devices currently driven by ixgbe driver:
# driverctl -v list-devices | grep ixgbe
0000:01:00.0 ixgbe (Ethernet 10G 4P X520/I350 rNDC)
0000:01:00.1 ixgbe (Ethernet 10G 4P X520/I350 rNDC)
Change them to use the vfio-pci driver:
# driverctl set-override 0000:01:00.0 vfio-pci
# driverctl set-override 0000:01:00.1 vfio-pci
Find devices with driver overrides:
# driverctl -v list-devices|grep \\*
0000:01:00.0 vfio-pci [*] (Ethernet 10G 4P X520/I350 rNDC)
0000:01:00.1 vfio-pci [*] (Ethernet 10G 4P X520/I350 rNDC)
Remove the override from slot 0000:01:00.1:
# driverctl unset-override 0000:01:00.1
The other reason for posting here is: is there interest in having such a
utility would find home in udev/systemd?
Note that I'm not trying to sell you the current shell-spaghetti
implementation, its mostly just a demonstration of the interface which
is modeled after the various *ctl utilities in systemd. The idea is to
rewrite it properly in C anyway, but at this point it'd be useful to
know from style/infrastructure/etc perspective whether there's interest
in having such a thing included in systemd afterall.
version 0.2?
driverctl + udevadm + add/edit/test/del udev-rules files (rather than working
with files directly) = udevctl™
e.g.
# udevctl --driver list-devices | set-override | unset-override ...
# udevctl --admin control | hwdb | monitor ...
# udevctl --rule add | edit | test | del ...
...
I personally have no aspirations to write a udev Swiss army knife.
It could of course write udev rules directly, the extra config file
approach makes it simpler to manage, eg if the udev rule needs changing
it can be easily changed in packaging instead of having to munge unknown
number of udev configuration files on disk and hope not to trample any
manually created rules in the process.
- Panu -
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
