Hi Isaac, Excellent point about vdev_linux_sysfs_read_device_mode(). For the very reason you mentioned, that code is on the way out. It was (incorrectly) used in a couple other places in the past before I knew better, but right now it's only use is in confirming that a device that has a known major and minor number and is known not to be a block device is, in fact, a character device. I just pushed code that makes this check more explicit and removes this method.
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? 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. 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). -Jude On Mon, Jan 19, 2015 at 6:17 PM, Isaac Dunham <ibid...@gmail.com> wrote: > 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 >
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
