As far as I understand, Vdev goes beyond being an alternative to
Systemd-Udev: it also aims at providing the possibility to give a
per-process view of the device special files - I personnaly haven't any
need of that. Its implementation differs strongly from Udev, which makes
it necessary to have a different library for applications (libudev-compat).
For what regards complexity, I cannot tell which one is the most
complicated. The biggest problem for me is that none of these tools has
set an obvious standard on how to pass information from the hotplugger
to the applications invoking the library. Another issue is that the
library provides functions for the use of the hotplugger itself and
functions for external applications, and it is not obvious which subset
is destinated to external applications.
Mdev (Busybox), on the other hand, is much simpler and has
significant advantages for small systems, but it does not interface with
a libudev, which is a problem for some applications, like X.org when it
is running without config files.
I mentionned Mdev here to try give a complete view and because it
makes sense in a minimal install. It would make sense to provide all 3
systemd-free hotpluggers in Devuan, if possible, for freedom of choice.
For what regards initramfs, AFAIU the packages involve an initramfs
part, which means that they insist on having the very same hotplugger
running during the initramfs phase and after. If the hotplugger is
restarted when entering the final rootfs, then I don't see any need for
having the same one before the pivot-root or switch-root. It would be
simpler to run Mdev in the initramfs. I have done this already on custom
debian systems.
Didier
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
