The future of kqueue(); mostly about vnode watching

[Ben Woolley]

I was thinking that some of the new FS features may be used to improve kqueue's features, specifically the vnode watching, and that you might have some other ideas relating to kqueue. The man page says that it is only possible to watch a vnode on a UFS. I am wondering a few things:

Will your VFS and/or journal changes make watching all FS types easier? I just reread your description of the journaling topology, and it looks like any type of VFS can support it eventually. I imagine one could just use a journal FD to globally watch a filesystem instead of watching a set of files via kqueue. But wouldn't kqueue be able to take advantage of the internal changes to support more FS types? Would that be better than how it is implemented now, besides just for portability, but also
 speed?

Ultimately, could vnode watching for many filesystems be done in a way that doesn't require any additional work on each filesystem beyond what you already have planned?

Do you plan to add EVFILT_FS and EVFILT_NETDEV like FreeBSD 6-current and darwin? Do you have ideas for other filters or features?

What do you think about an EVFILT_VFS that does a lot more than EVFILT_VNODE? For example, you create an EVFILT_VFS using the journal FD as the ident, set fflags to NOTE_USER_WRITE, and set data to a UID. This could be used to notify when user www writes to /tmp. Is that kind of thing over the top?

Could kqueue be useful for watching kernel message status?

Do you think your work will break any of kqueue's features for a long time?

What are your ideas on kqueue's design and features in general? You seem to take a lot of care in how to handle blocking, and I am thinking you have a lot of interesting things to say about the right way to do event notifications. 

Cheers,

Ben Woolley
http://tautology.org/