On Tue, Apr 07, 2015 at 02:04:36PM -0400, Jude Nelson wrote:
> Hi Scooby,
>
> >> My tentative solution is to require the device manager (whatever it
> >> happens to be) to take one extra step in addition to adding/removing device
> >> files: record driver core uevents in a well-defined location in /dev (let's
> >> say /dev/uevents/), so libudev clients can discover them (with inotify(2)),
> >> read them, and send them off to their applications. This can be done
> >> without loss of generality in udev, vdev, and mdev, and I can make a script
> >> that takes the appropriate action with mknod (so those with a static /dev
> >> can alias "mknod" to the script, if desired).
> >>
> >
> > So you want to split up the "listen to kernel driver core uevents" part
> > and vdev right?
> >
> > I saw you mentioning Isaac Dunham's libsysdev in another message.
> > It is a replacement for libudev, right?
> >
>
> 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.
> > 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.
> > 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.
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?
Thanks,
Isaac Dunham
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
