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
> >>
> >
> >