Hi Jaromil, > outstanding good news! congrats :^) if we manage to include vdev in > Devuan for upcoming releases you may acquire rather wide testing grounds > for your software.
Thanks for the encouragement :) When it comes to packaging vdev, what I'll do is add an /etc/alternatives entry for the system's device manager, and modify the device manager init script and initramfs hooks to use it. It should be possible for the user to install and select between multiple different device managers. This way, people can use whatever works for them. > I'm curious how you think we should plan this? as with all udev, also > libudev is now part of systemd, part of their tactical move to lockin > everyone rather than keep the codebases separate. The tie-in to systemd comes through its increasing dependence on some string utility methods systemd has (nothing that can't be put into a small util.c file in libudev), as well as the recent switch-over to including the hardware database parser in systemd. I'll just lift out the hwdb parser and put it back into libudev (or get a copy from eudev). libudev doesn't really do that much. It's basically a front-end for (1) reading data from sysfs, (2) querying the hardware database, and (3) getting information from udevd. I've already had to address a good chunk of (1) in the Linux port of vdevd, and most of (3) can be handled simply by watching /dev for changes and looking up newly-added device node metadata from sysfs. > how many applications actually require using libudev? Lots of middleware programs do. udisks2, lvm2, mountall, ConsoleKit, bluez, gvfs, kde-workspace-bin, pulseaudio, plymouth, multipath-tools, spacefm, v4l-utils, vlc-nox, and xserver-xorg-core are all compiled to rely on libudev, for example. > shall we fork libudev back out of systemd (libvdev?) That's my plan. I'm calling it libudev-compat, though (libvdev is already taken--it holds common code between vdevd and vdevfs). vdevd doesn't need a library to communicate with it. It stores all the information you'd get from udevadm under /dev/vdev/NAME_OF_DEVICE as a set of files, so programs can just read it or inotify-watch it directly. > what else? we may also advertise to upstream developers the alternative > and ask them to include a --with-vdev flag or so, linking to your api. Hopefully not even that. If I can supply a libudev workalike, they shouldn't have to do anything. -Jude On Tue, Mar 24, 2015 at 6:36 AM, Jaromil <jaro...@dyne.org> wrote: > On Tue, 24 Mar 2015, Jude Nelson wrote: > > > I'm pleased to announce that vdev can successfully boot to a > > console on the Devuan vagrant image!* It creates all requisite > > device files and loads all requisite kernel drivers, both for the > > pre-boot initramfs environment (so init can mount root) and in the > > early boot environment (while root is mounted read-only).* > > outstanding good news! congrats :^) if we manage to include vdev in > Devuan for upcoming releases you may acquire rather wide testing grounds > for your software. > > > We're well on our way now to replacing udev entirely.* The only > > big-ticket item remaining prior to an official alpha release is > > patching libudev so it does not need to talk to udevd to query > > devices.* This is only necessary for applications that require > > libudev. > > I'm curious how you think we should plan this? as with all udev, also > libudev is now part of systemd, part of their tactical move to lockin > everyone rather than keep the codebases separate. > > how many applications actually require using libudev? > > shall we fork libudev back out of systemd (libvdev?) > > what else? we may also advertise to upstream developers the alternative > and ask them to include a --with-vdev flag or so, linking to your api. > > ciao > > > >
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
