Hi Steve,

libdevq is FreeBSD-specific, and libsysdev would probably be the only
libudev-compat dependency on Linux besides libc and friends.

vdev is almost ready for some initial testing. It still needs some
boilerplate code and an init script, but I plan on adding that next. My
latest patches were focused on removing the C++ dependency, so you don't
need /usr to be mounted on boot.

vdev outsources most of its device initialization functionality to shell
scripts that get invoked on device discovery. A big part of the remaining
functional gap between udev and vdev is in writing shell scripts that set
up all the persistent names that udev rules set up (i.e. things like the
symlinks in /dev/input/by-path or /dev/disks/by-id, etc.). I'm about
half-way through that. It's slow-going, since udev's helper programs that
get the requisite information for persistent names are sparsely-documented
at best, as are the rules files and the persistent naming conventions (if
someone has some good documentation on this, I'd love to know about it).

The other big functional gap is in getting vdev to set up network
interfaces--namely, giving them persistent names, and (specific to
Debian/Devuan) invoking the ifupdown framework. I'm not that well-versed
with ifupdown since I've always used my own scripts for setting up my
network, but at some point I'll have to figure out how to do this.
However, the implementation strategy is the same--it's just a matter of
writing a shell script for vdev to invoke when it discovers a network
device.

I'll post tarballs as soon as I've gotten vdev to the point where I can use
it to boot up a VM :)

-Jude

On Thu, Jan 22, 2015 at 10:32 AM, Steve Litt <slitt@???>
wrote:

> Cool Jude!
>
> As a member of the "minimum dependencies" crew, I just have to ask:
> Would libsysdev, libdevq et al already be installed on a native Systemd
> installation? It's important that vdev be easily installable, without
> too much dependency hell.
>
> Please tell me when vdev is ready for testing on systems like
> Manjaro-systemd and CentOS. I'll derive great satisfaction from further
> incursions into Redhat's territory.
>
> Thanks,
>
> SteveT
>
>
>
> On Thu, 22 Jan 2015 10:09:50 -0500
> Jude Nelson <judecn@???> wrote:
>
> > Hi Steve,
> >
> > That's the plan :). However, one aspect of replacing udev with vdev
> > is making a libudev compatibility library that will let us use exiting
> > programs and libraries (like Mesa) without having to patch them. This
> > libudev-compat will probably make use of libsysdev and possibly
> > OS-specific libraries like libdevq, and for inspiration I was looking
> > at what other OSs do to address the lack of udev (it seems they have
> > been patching out libudev support so far, but it also looks like this
> > is getting harder and harder). If possible, I'd write libudev-compat
> > so that it won't even depend on vdev--ideally, people could use it
> > with a static /dev if they wanted, or some other non-Linux device
> > manager like devfs.
> >
> > -Jude
> >
> >
> >
> > On Thu, Jan 22, 2015 at 9:54 AM, Steve Litt
> > <slitt@???> wrote:
> >
> > > Hi Jude,
> > >
> > > I thought you were making vdev to plug replace udev. By the way,
> > > when it's ready, I have several Epoch and runit experimental setups
> > > I'd like to use it on.
> > >
> > > Thanks,
> > >
> > > SteveT
> > >

> > > Steve Litt                *  http://www.troubleshooters.com/
> > > Troubleshooting Training  *  Human Performance

> > >
> > >
> > >
> > > On Thu, 22 Jan 2015 09:50:11 -0500
> > > Jude Nelson <judecn@???> wrote:
> > >
> > > > I was looking through how FreeBSD handles the lack of udev while
> > > > still supporting Mesa, and it seems they patched it to use their
> > > > libdevq [1]. I wonder if there's some overlap with libsysdev
> > > > here that can be put to use for us...
> > > >
> > > > -Jude
> > > >
> > > > [1] https://github.com/freebsd/libdevq
> > > >
> > > > On Tue, Jan 20, 2015 at 12:01 AM, Jude Nelson <judecn@???>
> > > > wrote:
> > > >
> > > > > Hi Isaac,
> > > > >
> > > > > > I was asking about implementation details (something like the
> > > > > > HACKING document that many projects have, giving an overview
> > > > > > of how it works internally).
> > > > >
> > > > > Good idea; I'll add one.
> > > > >
> > > > > > I'm getting the impression that libsysdev won't really make a
> > > > > > good backend for the udev API; libudev is a much more
> > > > > > low-level interface, with somewhat different logical division
> > > > > > and flow. (Abstractly, I'd be happy if it did work. But
> > > > > > wasting time for the sake of promoting libsysdev isn't going
> > > > > > to help replace udev.)
> > > > >
> > > > > Interestingly, the libudev API doesn't look that tightly
> > > > > coupled to the udev implementation to begin with, which is why
> > > > > I consider libudev-compat to be feasible. Namely, I'm going
> > > > > with the following implementation strategy:
> > > > >
> > > > > udev: library state catch-all
> > > > > udev_list: this is just a linked list implementation of (key,
> > > > > value) pairs, which some other methods in libudev happen to
> > > > > return udev_device: mostly, this is reading data from sysfs
> > > > > and /dev. Not sure yet about device properties, but I'll
> > > > > figure something out. Might want to use libsysdev here, and/or
> > > > > recycle parts of vdev's linux back-end. udev_monitor: don't
> > > > > even bother with netlink. Just inotify-monitor /dev for
> > > > > changes, so even a static dev will generate events.
> > > > > udev_enumerate: this is just applying a generic set of filters
> > > > > on a sysfs directory listing. udev_queue: don't bother
> > > > > connecting to udev. Just inotify-monitor /dev again, but do so
> > > > > in the background (i.e. on library init). udev_hwdb: read udev
> > > > > hwdb files udev_util: only one string-encoding method; nothing
> > > > > to see here.
> > > > >
> > > > > -Jude
> > > > >
> > > > >
> > > > > On Mon, Jan 19, 2015 at 10:55 PM, Isaac Dunham
> > > > > <ibid.ag@???> wrote:
> > > > >
> > > > >> On Mon, Jan 19, 2015 at 08:56:10PM -0500, Jude Nelson wrote:
> > > > >> > Regarding the architecture, I have a design document here:
> > > > >> > http://judecnelson.blogspot.com/2015/01/introducing-vdev.html
> > > > >> > Is this
> > > > >> what
> > > > >> > you're looking for? Or did you want a more low-level
> > > > >> > document
> > > > >> describing
> > > > >> > the implementation details?
> > > > >>
> > > > >> I was asking about implementation details (something like the
> > > > >> HACKING document that many projects have, giving an overview of
> > > > >> how it works internally).
> > > > >>
> > > > >> Being mainly acquainted with C, I might not be able to follow
> > > > >> it myself, but it may well be useful for people who want to
> > > > >> contribute.
> > > > >>
> > > > >> > Regarding whitespace, my style is based on Stroustrup's
> > > > >> > adaptation of
> > > > >> K&R.
> > > > >> > I add whitespace where I do because it helps me read code
> > > > >> > better and add comments.
> > > > >>
> > > > >> Ah.
> > > > >> I find that the Linux kernel style (also based on K&R) seems
> > > > >> most clear to me; it seems quite different on the surface.
> > > > >> (Styles are styles, though. There's always variation.)
> > > > >>
> > > > >> > Looking forward to seeing what you do with libsysdev :) I'm
> > > > >> > seriously considering moving libudev-compat out of vdev
> > > > >> > entirely, and having it
> > > > >> use
> > > > >> > libsysdev as a backend (either way, I don't want it to be
> > > > >> > coupled to
> > > > >> vdev).
> > > > >> >
> > > > >>
> > > > >> I'm getting the impression that libsysdev won't really make a
> > > > >> good backend for the udev API; libudev is a much more low-level
> > > > >> interface, with somewhat different logical division and flow.
> > > > >> (Abstractly, I'd be happy if it did work. But wasting time for
> > > > >> the sake of promoting libsysdev isn't going to help replace
> > > > >> udev.)
> > > > >>
> > > > >>
> > > > >> Thanks for the comments!
> > > > >>
> > > > >> Isaac Dunham
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>