On 10/13/2015 03:28 PM, Harald Hoyer wrote:
On 13.10.2015 14:08, Panu Matilainen wrote:
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
If both kernel modules are already in the initramfs, you don't have to do this.
'dracut -f' is necessary to get any new/changed/removed
/etc/driverctl.d/ bits into the initramfs though.
I had not considered the modules question at all, which is of course
another valid concern, these non-default drivers might well not be in
the initramfs by default.
Thanks,
- Panu -
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
