Re: [RFC][PATCH] inotify 0.9

[Bill Davidsen]

On Thu, 16 Sep 2004, Chris Friesen wrote:

> Bill Davidsen wrote:
> 
> > If I were doing this, and I admit I may not understand all of the 
> > features, I would have a bitmap per filesystem of inodes being watched, 
> > and anything which did an action which might require notify would check 
> > the bit. If the bit were set the filesystem and inode info would be 
> > passed to user space which could do anything it wanted.
> 
> How do you identify the filesystem?  Whose mount namespace do you use if you 
> have multiple processes in different namespaces watching what is really the same 
> file?

You're asking for implementation details on something I threw out off the
top of my head? My first thought is "not by name" since if this is an
unmount that's not going to work well. Since I'm making this up, let's say
a filesysem number and inode number. Then when the watch is set the system
just has to have a unique "filesystem number" identifier which is shared
by every watch request against the f/s.

I haven't looked at how the original proposal handles things like the same
f/s mounted multiple times, etc, so I wouldn't venture to improve on it.
If I were actually going to write something like this, I'd want to start
with a description of functional requirements and response time, and go
from there, trying to move as much as possible out of unpageable memory.

-- 
bill davidsen <davidsen@xxxxxxx>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/