Scooby, John Carline, lepoitr, and others (who wish to remain anonymous)
> have been sending me logs filesystem listings from running vdev locally. I
> very much appreciate it--it helped me discover and fix bugs relating to
> persistent paths for disk devices, seeding /dev with initial device files,
> and adding support for Virtualbox USB devices. Thank you to everyone who
> helped me with this!
>

Thank you for taking on this hard task



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



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

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?


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

best regards

Scooby