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...@gmail.com> 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@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng