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
>