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.ag@???> 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@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>