Re: inotify/sysfs

[Al Viro <viro@ZenIV.linux.org.uk>]

On Thu, Mar 27, 2014 at 02:50:24PM +0100, Quentin Glidic wrote:
> Hello,
> 
> In GIO (GLib), the GFileMonitor[1] mechanism is using inotify for
> local files. To detect file creation and some other weird cases,
> they monitor the directory of the file and not the file directly
> (see get_basename/get_dirname[2] usage).
> 
> With sysfs, it does not work as expected for some reason.
> 
> From a quick discussion of IRC with GLib folks, it appears that it
> would be better fixed in sysfs directly.

inotify does not and will not work on sysfs.  Or procfs.  Or devpts.  Or
any number of network filesystems.  No matter how hard somebody might wish
it to work, that's simply not feasible.

Linus, what do you think about flat-out refusing to create the watches on
filesystems that can't support them?  At inotify_add_watch(2)/fanotify_mark(2)
time.  Do you think that it would break syscall ABI warranties?  As it is,
the caller has no way to tell it needs to go for a fallback, short of
getting ENOSYS on inotify_init().  And it *does* need to have fallback,
simply because there's no way in hell to get notifications for a lot of
places in synthetic filesystems, etc.

If userland developers pull that kind of stunts (see above re GLib crowd
trying to defend their garbage by suggesting that kernel must somehow
make *notify work on all filesystems), we'd better push back before that
behaviour spreads.

BTW, inotify(7) and inotify_add_watch(2) need to be fixed - they do not
mention these limitations at all.  Assuming that reader has a clue and
realizes that there's no magic is not a good idea...