Le 24/12/2020 à 10:23, aitor a écrit :
>
> 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.


    Aitor I think you are the only person who knows vdev in depth.
Therefore only you can decide what the best approach is, keeping in mind
the amount of work is implied by the maintenance. I also agree that a
tool to compile the database would be helpfull.

--     Didier