On Wed, 17.12.14 13:13, Karel Zak (k...@redhat.com) wrote: > On Fri, Dec 12, 2014 at 08:11:54PM +0100, Lennart Poettering wrote: > > > I guess it's enough to add the 'fd' to systmed sd_event_add_io() and > > > call mnt_table_parse_mtab() when a change is detected. (As already > > > implemeted in the original Chris' patch.) > > > > Karel, if I got this right, then the new monitor stuff will only wrap > > inotify on utab, right? I think it would be useful if it would also > > abstract notifications via /proc/self/mountinfo in it. To make the > > interface easy for this and to be able to just hand out a single fd, > > this would mean creating an epoll fd inside the lib, then adding the > > inotify fd for utab to it, and then on top the EPOLLPRI watch on > > /proc/self/mountinfo. > > > > This way apps would get the full set of notifications via your > > library, without knowing what's going on underneath, and userspace > > notifications and kernel notifications would come the same way. > > OK, implemented (util-linux "monitor" branch on github). > > But I have changed the userspace monitor to care about > /run/mount/utab.lock file. It's better than the original Chris idea > (monitor all /run/mount directory for utab rename changes). This new > solution is without possible false positives.
Not following here. As long as everybody writing utab moves the file atomically into place I see no reason to watch the lock file ever. > > This is important details, because if you use epoll file descriptor > in another epoll then you're correctly notified on the top-level epoll, > but you lost information about which underneath file descriptor is active > -- then it was impossible to verify the inotify IN_MOVED_TO utab > event. Hmm? Not following. The top-level epoll will get an event telling you that which low-level epoll is triggered. Then, you read an event from that which tells you precisely which actual file has been triggered... > The another advantage is that the event is triggered really after utab > update (the update is covered by flock, and close() means unlock). > > Now: > > your-epoll > | > library-epoll-FD > / \ > mountinfo-FD utab.lock-inotify-FD > > > Note that after notification it's necessary to cleanup (drain) inotify > bufferes, so I have added mnt_monitor_event_cleanup(). Yupp, makes sense. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel