Hi,

> On 19/12/20 15:10, Didier Kryn wrote:
>>     I think that, like in the case of Mdev, the biggest difficulty is in
>> emulating libudev, which requires in particular to maintain an
>> up-to-date database of devices. Jude has done a complete job and libvdev
>> provides this emulation, but who maintains the database ?

I've been working on vdev during these days, and i'm thinking on a
possible new approach for it. For instance:

1) We should consider whether or not a separate ABI (libudev-compat) is
required since the apparition
of libeudev1 (libudev1 without systemd), or leave instead this other
library (compatible  with libeudev1, or
better said, depending on it) for new features added by Jude Nelson and
contributors (say the whole libudev-fs.c
or some add-ons like "udev_monitor *udev_monitor_new_from_filesystem" in
libudev-monitor.c, non existent
in libeudev1)

2) We should also consider the inclusion of a hardware database
management  tool, call udevadm, vdevadm or
whatever you want. I propose this addition due to the slow boot of the
system caused by the lack of  this tool,
i guess. In the case of eudev, the hardware database is compiled into a
binary and only the binary is used at
runtime. I should however add that yesterday I handled vdev with runit
and the boot process was very quick,
but there is a drawback here: you need to wait for the hardware to be
detected. In a console session I needed
to wait for the detection of wlan0 (even eth0 was detected inmediately);
in a X session I couldn't login because
neither the mouse nor the keyboard didn't respond.

Cheers,

Aitor.