[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