[systemd-devel] [PATCH v2 5/5] mount: auto-detect iSCSI and FCoE as requiring network

[Lennart Poettering]

On Mon, 01.12.14 16:47, Karel Zak (kzak at 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