Autor: Joel Roth Data: Dla: dng Temat: Re: [DNG] vdev (was: Re: if2mac init.d service for persistent
network interface names)
Hi Aitor,
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 think that's okay, because Probably most potential users
of vdev will be using a lightweight window manager or even
just console. I think serving that group will be a good
place to start.
Also, while a database for fast startup would be great,
enabling it to work at all would be a good first step.
Eventually some sort of write-up about vdev comparing it to
mdev, udev, eudev might help getting the word out. (I'd
help with that.)