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
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
