Le 30/12/2020 à 20:51, Joel Roth via Dng a écrit :
> On Thu, Dec 24, 2020, aitor wrote:
>> Hi Joel,
>>
>> On 24/12/20 7:40, Joel Roth wrote:
>>> Thanks for looking into this! I, for one, don't need
>>> to run KDE or Gnome.
>> 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.
> While I don't understand your post completely, I agree with
> your point that udev-compat need not be a high priority as
> libeudev meets this need. I understand that without
> udev-compat, vdev wouldn't be able to serve some heavyweight
> desktop environments.

    I'm not absolutely sure of what I write there, but it seems to me
that libeudev and eudev work together and the second contributes to fill
the data structures maintained by the first.

--     Didier