aitor said on Sat, 12 Jun 2021 00:46:08 +0200


>Thanks, Steve, it's named Hopman. A project started by Didier Kryn. At
>the beginning my point of view was quite different
>because, on the contrary than Didier's design, i didn't use inotify to
>become aware of any kernel uevent. The reason why
>i avoided inotify was related to some missing symlinks in /dev/disk
>when using vdev as device manager (hopman will be
>compatible with both eudev and vdev, and i wanted to use this
>directory as one of the wathdirs for inotify). Now i'm
>considering as a possible better approach to create vdev actions for
>each (ADD|REMOVE|CHANGE) device events, and their equivalent
>udev rules for eudev to trigger them in a way that hopman only will be
>notified about changes in the /proc/mounts file
>whenever the user uses pmount or any similar tool -via the gui of
>hopman- to mount/unmount partitions.

Hi Aitor,

Inotify is the Linux-official way of finding device events. As far as I
know, inotify doesn't care whether you use udev, eudev or vdev, which
in my opinion makes it superior. I'd prefer not to have a Hopman with
all sorts of logic if vdev, elsif eudev, else udev, ESPECIALLY if the
device handler decision is made at compile time. Only slightly
better would be to have three Hopmans: One for each device handler.

If there are missing symlinks in /dev/disk, why not fix that root cause
and let the inotify authors worry about different device handlers,
rather than base your program logic on something the systemd people can
change any time, possibly forcing vdev and eudev to change in order to
keep up?

I've used inotify: It's an excellent way to find specific events,
although the filtering of the event stream is somewhat complex. Why not
reconsider using inotify?

Thanks,

SteveT

Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques