Re: GSoC 2011 project proposal [Add kqueue support to GIO]

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Tue, 29 Mar 2011 10:17:26 -0500
David Young <dyoung%pobox.com@localhost> wrote:

> Are you sure that kqueue supports monitoring trees?  I know that
> it's possible for to watch a directory with kqueue for nodes
> added/deleted/renamed, however, when a process watches directory x/ with
> kqueue it won't necessarily wake up if there is a change under x/y/ or
> x/y/z/.

I remember participating to an older thread on this subject here years
ago, and indeed kqueue lacks the ability to monitor trees.  If I
remember, one of the conversations did evolve around the possibility
for kqueue to eventually be able to report events for a whole
filesystem, although if this was done the security model has to be
thought of carefully.  An event could for instance hold the following
fields: inode, event, nparams, params[] or the like.

I'm not sure if this is a requirement for inotify, but another
potential issue is the reverse mapping of inodes to paths; also long
ago I implemented a userland daemon to do this and realized that for
large trees the memory requirements were rather large (I didn't bother
implementing compression for it though).  Of course this gets
complicated by the fact that multiple paths may lead to a common node,
but it wouldn't be very hard for the kernel to remember one of the
paths to every active vnode, possibly...  which would also benefit
fstat(1) and procfs...
-- 
Matt