Monitoring FS changes

[Jordan Hubbard]

> On Jan 4, 2016, at 7:43 PM, Bakul Shah <bakul at bitblocks.com> wrote:
> 
> Why not do this (at least at first) in a user mode program?
> Intercept FS system calls and write relevant info to a user
> program's memory.  You still need to add a syscall to watch
> files/dirs for various events and to validate requests. This
> will allow you to experiment with various implementations
> before commiting to a complicated new mechanism in the kernel.

That’s basically how FSEvents work.  There’s a fairly straight-forward (Mach IPC based) kernel upcall mechanism for communicating the filesystem change events (and control inputs for what to watch) to a daemon, fseventsd, and it’s the userland daemon which subscribers talk to and it figures out how many events to cache, when all subscribers have received the events (or timed out) and it can re-use the memory, and so on.

The kernel reporting mechanism can be relatively light-weight if you proxy all the subscription and memory management details through a userland daemon, which is why I certainly wouldn’t suggest doing it any other way…

- Jordan