[lkml]   [2001]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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.

It makes security checks impossible though. You would have to reboot
the system every time a directory changes permission to block unauthorized
monitoring of files that are no longer accessable by the user.

Jesse I Pollard, II

Any opinions expressed are solely my own.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.037 / U:2.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site