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
