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