Cool Jude! As a member of the "minimum dependencies" crew, I just have to ask: Would libsysdev, libdevq et al already be installed on a native Systemd installation? It's important that vdev be easily installable, without too much dependency hell.
Please tell me when vdev is ready for testing on systems like Manjaro-systemd and CentOS. I'll derive great satisfaction from further incursions into Redhat's territory. Thanks, SteveT On Thu, 22 Jan 2015 10:09:50 -0500 Jude Nelson <jud...@gmail.com> wrote: > Hi Steve, > > That's the plan :). However, one aspect of replacing udev with vdev > is making a libudev compatibility library that will let us use exiting > programs and libraries (like Mesa) without having to patch them. This > libudev-compat will probably make use of libsysdev and possibly > OS-specific libraries like libdevq, and for inspiration I was looking > at what other OSs do to address the lack of udev (it seems they have > been patching out libudev support so far, but it also looks like this > is getting harder and harder). If possible, I'd write libudev-compat > so that it won't even depend on vdev--ideally, people could use it > with a static /dev if they wanted, or some other non-Linux device > manager like devfs. > > -Jude > > > > On Thu, Jan 22, 2015 at 9:54 AM, Steve Litt > <sl...@troubleshooters.com> wrote: > > > 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
