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 <jaromil@???> 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
>
>
>
>