On Mon, Jan 19, 2015 at 04:05:46PM -0500, Jude Nelson wrote: > Hey Isaac, this looks great! Starred and watched :)
Thanks! > Related, I've just committed some (very) preliminary code for > libudev-compat in the vdev repository that's meant to be both API and > ABI-compatible with libudev. I think we're working towards the same > end--make a library that can replace libudev but without depending on a > specific device manager. Glad to hear about this. I note that udev supposedly uses/used libsysfs, in case that's useful information. udev exposes a *lot* of its internals. > If you're interested, I have some sysfs-parsing code written and tested for > vdev's Linux back-end, located here [1]. You might find it useful to > libsysdev. It's available under either GPLv3+ or ISC. > > -Jude > > [1] https://github.com/jcnelson/vdev/blob/master/vdevd/os/linux.c Thanks for the link. Reading it over, it seems our purposes are roughly inverse: vdev starts with DEVPATH, parses information, and spits out a device. libsysdev starts with a device, finds something like DEVPATH, and spits out either said path or information available there. So far, the only information libsysdev gets is PCI ids, and as far as I can see vdev mainly checks device type and uevent information. I'm planning to add a little more code for the sake of easily finding which input devices are what type, to aid in configuring X sans udev. I've used Xfbdev and similar stuff, but often find myself wondering where the keyboard is. Now, a few comments/questions on your code: * While the mechanism is clear for most of it, I find myself wondering how vdev_linux_sysfs_read_device_mode() works. If I'm following it correctly, you're just assuming that either /sys/dev/char/%u:%u exists and it's a character device, or /sys/dev/block/%u:%u exists and it's a block device. This will break as soon as you hit /dev/ram*, since they have the same major/minor numbers as /dev/{mem,kmsg,null,full,port,zero,random,urandom} It seems that you can use the inodes from stat() instead. * Is there some file explaining the overall architecture? * What coding style are you using? While I've seen styles both more and less legible, I haven't run across anything that uses that much whitespace. Thanks, Isaac Dunham _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
