On Mon, 01.12.14 16:47, Karel Zak (k...@redhat.com) wrote: > On Mon, Dec 01, 2014 at 02:28:33PM +0100, Zbigniew Jędrzejewski-Szmek wrote: > > > Wouldn't be enough to use Chris' iSCSI and FCoE auto detection? > > Please see previous discussion... Detecting network might not be trivial > > if the devices are layered and there's a network-requiring device somewhere > > lower in the stack. > > Good point. (It would be possible to analyze whole stack by slave/holders > relations, but I agree it's too complex and probably too fragile.) > > > > Anyway, if you still want to read userspace mount options than I can > > > add something like: > > > > > > mnt_inotify_mtab_add_watch() > > > mnt_inotify_mtab_rm_watch() > > > mnt_inotify_mtab_changed() > > > > > > to hide all the paths and private mtab/utab stuff. > > Maybe something more like what journal client code does here: > > > > mnt_mtab_get_fd() -> epoll fd > > mnt_mtab_get_events() -> EPOLLIN|EPOLLPRI > > mnt_mtab_process() -> information what changed > > Hmm.. utab is optional and very often does not exist, and library > uses rename(2) to do atomic update of the file. This is reason why > Chris have used inotify for /run/mount directory (and Lennart asked > for inotify API). I have doubts you can use epoll to monitor > directories, epoll is about I/O monitoring.
Well, what Zbigniew was suggesting is to hide the fact that inotify is used away, and instead do that internally. I.e. provide three calls: one that tells the user of this the fd to listen on, the second that tells the user of this the poll events to listen on, and finally one function to call when actually one of those poll events is triggred. 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? 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. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
