Implications of installing eudev/libudev

[dl12345]

I'm trying to port the Intel Quick Assist firmware and drivers for the C3000 SoC to OpenWrt (I've previously ported and uploaded the ones for the C2000 SoC, which were easier by comparison due to less dependencies on external libraries).

The C3000 firmware and driver build system, however, requires libudev and the version exposed by libudev-fbsd is unfortunately not recent enough.

So, I've pulled the package Makefile for eudev from from the Openwrt/LEDE 17.x tree.

It may turn out that I just need to have libudev available in the staging tree in order to complete the build, since I will be using the upstream kernel driver and I don't think that the userspace component requiring libudev will be strictly necessary to install, in which case there is no potential conflict or incompatibility.

However, assuming I do need to install eudev/libudev on a running system, what implications if any are there? I recall seeing at one point in time some rumblings about incompatibility with procd....

[dl12345]

Ok, so I do need to install libudev.so onto a running system. Anyone able to give me some insight on how/whether this will interfere with other systems?

[Grommish]

I looked at the Github source and it hasn't been updated since 2017. I think if it doesn't do what you need, you should consider it abandoned?

You can find the Github here https://github.com/jiixyj/libudev-fbsd

[dl12345]

Thanks, yeah - it has not seen any update for a long time.

Firstly, thanks to @dangowrt for the help in an email.

It turns out that libudev-fbsd is extremely limited. It contains a lot of functions that are simply stubs, and packages relying on libudev functionality will break as a result, since these stubs return error codes due to the fact they're not implemented.

For anyone else landing on this topic with a search, here's some info that might be useful and save you an extended search.

Gentoo's libudev, available in the eudev package that can be found in the LEDE 17.x repo does actually work and does not interfere with procd.

I took the eudev package and cut it down so that it installed only libudev.so, which I used to link against my userspace tools. They're able to use the functionality successfully and there is no impact on procd or anything else.

Since procd handles hotplug events, however, one cannot and should not install udevd on an Openwrt system. However, procd is quite functional and will be able to process the hotplug events if the appropriate directories are created in /etc/hotplug.d.

Both udev and procd use the same netlink uevents, so they're not entirely incompatible. It's just udevd and procd that are incompatible.

While loading all the drivers, I ran eudev's udevadm monitor tool to see the UEVENTs that were generated. The output looked as follows:

KERNEL[90017.793925] add      /module/intel_qat (module)
KERNEL[90017.793955] add      /class/qat_adf_ctl (class)
KERNEL[90017.794006] add      /devices/virtual/qat_adf_ctl/qat_adf_ctl (qat_adf_ctl)
KERNEL[90017.794587] add      /class/qat_dev_processes (class)
KERNEL[90017.794616] add      /devices/virtual/qat_dev_processes/qat_dev_processes (qat_dev_processes)
KERNEL[90017.798617] add      /module/usdm_drv (module)
KERNEL[90017.798734] add      /class/usdm_drv (class)
KERNEL[90017.798758] add      /devices/virtual/usdm_drv/usdm_drv (usdm_drv)
KERNEL[90017.802777] add      /module/qat_c3xxx (module)
KERNEL[90018.391485] bind     /devices/pci0000:00/0000:00:06.0/0000:01:00.0 (pci)
KERNEL[90018.391549] add      /bus/pci/drivers/c3xxx (drivers)
KERNEL[90018.419919] add      /module/qat_api (module)
KERNEL[90020.260379] add      /devices/pci0000:00/0000:00:06.0/0000:01:00.0/uio/uio0 (uio)
KERNEL[90020.260437] add      /devices/pci0000:00/0000:00:06.0/0000:01:00.0/uio/uio1 (uio)
KERNEL[90020.260580] add      /devices/pci0000:00/0000:00:06.0/0000:01:00.0/uio/uio2 (uio)
KERNEL[90020.260621] add      /devices/pci0000:00/0000:00:06.0/0000:01:00.0/uio/uio3 (uio)
KERNEL[90020.260717] add      /devices/pci0000:00/0000:00:06.0/0000:01:00.0/uio/uio4 (uio)
KERNEL[90020.260796] add      /devices/pci0000:00/0000:00:06.0/0000:01:00.0/uio/uio5 (uio)
KERNEL[90020.260875] add      /devices/pci0000:00/0000:00:06.0/0000:01:00.0/uio/uio6 (uio)
KERNEL[90020.260982] add      /devices/pci0000:00/0000:00:06.0/0000:01:00.0/uio/uio7 (uio)
KERNEL[90020.261045] add      /devices/pci0000:00/0000:00:06.0/0000:01:00.0/uio/uio8 (uio)
KERNEL[90020.261146] add      /devices/pci0000:00/0000:00:06.0/0000:01:00.0/uio/uio9 (uio)
KERNEL[90020.261237] add      /devices/pci0000:00/0000:00:06.0/0000:01:00.0/uio/uio10 (uio)
KERNEL[90020.261291] add      /devices/pci0000:00/0000:00:06.0/0000:01:00.0/uio/uio11 (uio)
KERNEL[90020.261398] add      /devices/pci0000:00/0000:00:06.0/0000:01:00.0/uio/uio12 (uio)
KERNEL[90020.261470] add      /devices/pci0000:00/0000:00:06.0/0000:01:00.0/uio/uio13 (uio)
KERNEL[90020.261600] add      /devices/pci0000:00/0000:00:06.0/0000:01:00.0/uio/uio14 (uio)
KERNEL[90020.261649] add      /devices/pci0000:00/0000:00:06.0/0000:01:00.0/uio/uio15 (uio)

Every line in this output ends with something in parentheses. This corresponds to the directory name one needs to create in /etc/hotplug.d. So, in my case I needed to do a whole bunch of things mainly related to changing group ownership and permissions on files in /dev and creating other directories and mounting special filesystems when certain drivers were loaded.

So for the case of the usdm_drv kernel module you can see in the output, it sufficed to create a /etc/hotplug.d/modules folder and using the env command, output the environment passed into it, which then gave all the necessary info to create a functional hotplug script.

Similarly, I was able to create directories such as /etc/hotplug.d/qat_dev_processes, /etc/hotplug.d/class and /etc/hotplug.d/uio.