Hi Isaac,

[snip]

> >
> > libsysdev is meant to help clients pull information from sysfs. I don't
> > think it is supposed to help clients run privileged ioctls (Isaac, please
> > correct me if I'm wrong!).
>
> Not at present.
> It basically maps a device to a sysfs directory and possibly gets a
> *little* more info from that (currently just PCI IDs).
>
> You cannot make a library do anything privileged without either
> helper programs or a helper daemon.
> Personally, I'm inclined to think it would be nicer to use helpers...
> but there are limitations to both approaches.
>
> I suppose it would be *possible* to make it configureable which it does.
>

Certainly :) I'd like to support that in libudev-compat as an option at
some point.


>
> > > Can libsysdev do this part quoted below?
> > >
> > > "report every kind of device, since it listens to the kernel's driver
> core
> > > (i.e. libudev learns about network interfaces, buses, power supplies,
> > > etc.--stuff for which there are no device files"
>
> Currently, it doesn't *report* devices; that takes something longer term,
> like inotify, polling a netlink socket, or listening to a daemon.
>
> It also has no clue about events or hardware that could not have a
> corresponding device, since it uses block/char and major:minor to find
> the hardware.
>
> I have a general idea of how to get information like this, by recursing
> through /sys or /dev, and I know of some code I could use as a starting
> point, but I don't know what the ideal format is.
> If someone points me at a program they'd like to use without libudev
> (preferably C with minimal dependencies) that doesn't cover a lot of
> ground (ie, it's clear what functionality udev provides, and I wouldn't
> need to duplicate much of libudev to get it working), that would be a
> good starting point for expanding libsysdev.
>

You might find something useful in vdev_linux_sysfs_register_devices() and
vdev_linux_sysfs_find_devices() functions in vdevd/os/linux.c. They're
both involved in generating the initial coldplug device listing. They only
need libc to work, and libvdev/sglib.h for basic data structures.


>
> > > Is vdev and libsysdev tested together?
> > >
> >
> > They're currently not used together. Libsysdev is meant to help programs
> > that only need libudev for a few things (like querying sysfs) do so
> without
> > linking against libudev.
> >
>
> > > To avoid the troublesome corner case where a libudev client crashes and
> > >> potentially leaves behind a directory in /dev/uevents/, I would
> recommend
> > >> mounting runfs [1] on /dev/uevents. Runfs is a special FUSE
> filesystem I
> > >> wrote a while back that ensures that the files created in it by a
> > >> particular process get automatically unlinked when that process dies
> (it
> > >> was originally meant for holding PID files).
> Hmm...
> Do we need to have a subdirectory of the mountpoint?
> Could you just use ACLs if you need to make a limited subset available?
> I get the impression that we can do this for mdev via a script along
> these lines:

> FILENAME=`env | sha512sum | cut -d' ' -f1`
> for f in /dev/uevents/*
>         do env >"$f"/$FILENAME
> done

>
> but it would be *nicer* if we only needed to write one file.
>

I agree that one file per event is ideal (or even a circular logfile of
events, if we could guarantee only one writer). However, I'm not sure yet
what a fine-grained ACL for device events would look like. My motivation
for per-client directories is that unprivileged clients can be made to see
only its own events and no one else's by default (i.e. by chmod'ing the
directory to 0700), and that they make it easy reason about sending
post-processed events only to the clients you want--just change the list of
directories to iterate over in that for-loop :)


> Also, wouldn't mounting that with runfs result in records of uevents
> getting erased if they're written by a helper rather than a daemon?
>

Yes; good catch. There are a couple straightforward ways to address this:
(1) have a separate, unprivileged device-event-log daemon curate
/dev/uevents/ and have the helper scripts forward device events to it, or
(2) fork and/or patch runfs to allow files to persist if they're generated
by a certain whitelist of programs (i.e. all programs in a particular set
of directories, like /lib/vdev/), but disappear otherwise once the creating
process dies.


>
> Thanks,
> Isaac Dunham
>

Thanks for your feedback!
-Jude