On 09/30/2015 08:43 PM, Flavio Leitner wrote:
On Tue, Sep 29, 2015 at 12:30:54AM +0300, Mantas Mikulėnas wrote:
I wonder if this could be handled with a generic Type=oneshot,
ExecStart=driverctl bind foo...
Could you elaborate more on that?
If driverctl is an utility, we could use scripts, yeah. The issue
is how to identify the device. We probably would need some sort
matching mechanism like udev does.
Since the silence is deafening, and since its usually easier to poke
holes in something concrete no matter how incomplete and/or broken,
here's a beginning of an approach to alternative driver assignment in
the udev realm: http://laiskiainen.org/udev/driverctl/
# <copy/patch the bits to their places>
# echo vfio-pci > /etc/driverctl.d/0000:01:00.0
# echo 1 > /sys/bus/pci/devices/0000:01:00.0/remove
# echo 1 > /sys/bus/pci/rescan
...and there you go, udev vfio-pci is forced for that device on the
rescan, and a real hotplug is handled similarly.
Since normally the device probing occurs early in the boot, these things
also need to go to initramfs so a dracut module/patch is needed, and
dracut needs to be run after adding devices here, ie
# echo vfio-pci > /etc/driverctl.d/0000:01:00.0
# dracut -f
# reboot
Having to mess with initramfs is a bit of a PITA but at least some of
that could be hidden in the driverctl utility, and then overriding the
default driver early in the boot means we get none of the side-effects
with interfaces coming and going, possibly wrestling with NetworkManager
over it etc.
For a real-world implementation there are tons of TODOs like
- support non-pci buses
- support direct bind/unbind in driverctl
- million errors situations to check
- vfio & uio -bound devices disappear from systemd, we'd probably want
them there in some form to be able to depend on them
- etc...
- Panu -
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
