[systemd-devel] how to bind to other drivers using systemd
Harald Hoyer
harald.hoyer at gmail.com
Tue Oct 13 05:28:23 PDT 2015
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.
>
> 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 -
>
>
More information about the systemd-devel
mailing list