:: Re: [Dng] libsysdev preview
Pàgina inicial
Delete this message
Reply to this message
Autor: Isaac Dunham
Data:  
A: dng@lists.dyne.org
Assumpte: Re: [Dng] libsysdev preview
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