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 <jud...@gmail.com> 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 <jud...@gmail.com> > 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...@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
