Re: FS callback routines

[Daniel Phillips]

Jamie Lokier wrote:
> 
> Daniel Phillips wrote:
> >         DN_OPEN       A file in the directory was opened
> >
> > You open the top level directory and register for events.  When somebody
> > opens a subdirectory of the top level directory, you receive
> > notification and register for events on the subdirectory, and so on,
> > down to the file that is actually modified.
> 
> If it worked, and I'm not sure the timing would be reliable enough, the
> daemon would only have to have open every directory being accessed by
> every program in the system.  Hmm.  Seems like overkill when you're only
> interested in files that are being modified.

It gets to close some too.  Normally just the directories in the path to
the file(s) being modified would be open.

Good point about the timing.  A directory should not disappear before an
in-flight notification has been serviced.  I doubt the current scheme
enforces this.  There is no more room for 'works most of the time' in
this than there is in our memory page handling.

> It would be much, much more reliable to do a walk over d_parent in
> dnotify.c.  Your idea is a nice way to flag kernel dentries such that
> you don't do d_parent walks unnecessarily.

It's bottom-up vs top-down.  It's worth analyzing the top-down approach
a little more, it does solve a lot of problems (and creates some as you
pointed out, or at least makes some existing problems more obvious). 
For make it's really quite nice.  The make daemon only needs to register
in the top level directory of the source tree.  I think this solves the
hard link problem too, because each path that's interested in
notification will receive it.

--
Daniel