Hi Scooby,

[Snip]

>
>
>> However, this has proven to be a somewhat challenging problem, for a
>> couple reasons. First, inotify(2) does not work on pseudo-filesystems like
>> sysfs or devtmpfs, so we can't just watch /sys for changes, and we can't
>> use devtmpfs for /dev. This means that systems using libudev-compat will
>> require a "vanilla" tmpfs for /dev (or nothing at all), so it can detect
>> when devices are added or removed. Second, only block and character
>> devices show up in /dev. However, udevd reports 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). Clients will expect this behavior, so it's not enough to
>> simply look up a new block/character device's sysfs data.
>>
>
> Is this "listen to kernel driver core" something you don't want to do? If
> so is it because one of the project goals
> is to support several platforms i.e BSD?
>
> Or is it to keep it modular and not so interdependent?
>

Libudev clients expect to receive "post-processed" driver events from udev
via a dedicated netlink multicast group (defined as UDEV_MONITOR_UDEV in
libudev-monitor.c). Nothing stops libudev clients from opening their own
netlink socket and listening directly to messages in the
NETLINK_KOBJECT_UEVENT multicast group, but the advantage of listening to
udevd is that udevd takes care of parsing the uevent packet, looking up
extra metadata from sysfs and the hardware database, querying the device
(!!), and filling in a "struct udev_device" instance with all the
information it gathers.

The reason why libudev doesn't just do all of the above is because querying
the device is often a privileged operation, since it usually entails doing
specialized ioctls. This is why udevd (and vdevd and mdev) need to run as
root--the helper programs they run need to have sufficient privileges.
This isn't an option for libudev clients, though, which is why they need to
get device information from a device manager. My plan is to make vdevd
make this information available via the filesystem (for portability and
better access control), and patch libudev so clients can retrieve it.

Over in systemd-land, I'm pretty sure the plan going forward is to replace
netlink with kdbus to do the same task.


>
>
>> 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?
>

> Trying to figure this out
>

> 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!).


> 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"
>
> 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).
>>
>
>
> I tried runfs on my system that is using aufs and couldn't get it to run
> I got something like "Transport endpoint is not connected"
> This is not a problem for me since dev/ won't be persistent between boots
> so can run without runfs.
>

Interesting. Were you able to get runfs to run somewhere else, i.e. on a
temporary directory? Was there something else mounted there already that
crashed earlier?

If you run runfs with -f, it will run in the foreground, and that can tell
you if something is amiss (you can also run it in valgrind this way).
Runfs takes the standard FUSE options (-f for foreground, -s for
single-threaded, -o $FUSE_OPTION for FUSE-specific options, -d for FUSE
debugging output).


> best regards
>
> Scooby
>
>
>
Thanks,
Jude


>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
>