Date: Mon, 04 Jan 2016 21:33:43 -0800 From: Jordan Hubbard <jordanhubbard@icloud.com> To: Bakul Shah <bakul@bitblocks.com> Cc: freebsd-fs@freebsd.org Subject: Re: Monitoring FS changes Message-ID: <1CAAFE08-D24E-49AA-8EC5-4397A199DA3E@icloud.com> In-Reply-To: <20160105034327.B650FB827@mail.bitblocks.com> References: <201601041959.u04JxWGn053360@kithrup.com> <416747176.149128068.1451960539354.JavaMail.zimbra@uoguelph.ca> <20160105034327.B650FB827@mail.bitblocks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jan 4, 2016, at 7:43 PM, Bakul Shah <bakul@bitblocks.com> wrote: >=20 > 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=E2=80=99s basically how FSEvents work. There=E2=80=99s 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=E2=80=99s 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=E2=80=99t suggest doing = it any other way=E2=80=A6 - Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1CAAFE08-D24E-49AA-8EC5-4397A199DA3E>