On Fri, Dec 05, 2014 at 01:46:06AM +0100, Lennart Poettering wrote: > With such an API you have the liberty to change later on what > precisely you expose there. The fact that you watch a file would be > entirely opaque, it could one day be a pipe or socket, or even an fd > on some kernel fd, where you just tell us the kind of events you want > the user code to listen on. > > This is how we wrap a lot of our own APIs, to allow integration into > arbitrary main loops, without restricting us to decide how precisely > the event is generated. > > Does this make sense?
Yep. > Would love to get an API in place for this in libmount, because I > don't really want to release systemd with the current code. Implemented. I have added struct libmnt_monitor to make this new interface easy to extend and usable for more resources (I'll probably also add mountinfo fd for findmnt(8), but this is irrelevant for systemd;-) All you need is: mn = mnt_new_monitor(); fd = mnt_monitor_userspace_get_fd(mn, NULL); /* utab monitor fd */ mnt_monitor_get_events(mn, fd, &ev.events); /* EPOLLIN ... */ efd = epoll_create1(EPOLL_CLOEXEC); epoll_ctl(efd, EPOLL_CTL_ADD, fd, &ev); .... n = epoll_wait(efd, events, 1, -1); id (n == 1 && mnt_monitor_is_changed(mn, fd) == 1) printf("%s: change detected\n", mnt_monitor_get_filename(mn, fd)); .... mnt_unref_monitor(mn); close(efd); 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.) usable example: https://github.com/karelzak/util-linux/blob/master/libmount/src/monitor.c#L345 Karel -- Karel Zak <k...@redhat.com> http://karelzak.blogspot.com _______________________________________________ systemd-devel mailing list email@example.com http://lists.freedesktop.org/mailman/listinfo/systemd-devel