Dmitry Matveev <me%dmitrymatveev.co.uk@localhost> wrote:
> > Would be nice to provide a detailed description of what kqueue lacks
> > during the early stages of the project. It might be the case that
> > it's impossible to extend kqueue to implement some important
> > functionality... in which case we could be looking at a different
> > project altogether (e.g. implement inotify in the kernel)!
>
> I have found that kqueue does not have analogues to the following
> inotify events:
>
> 1. IN_ACCESS - File was read from
> 2. IN_OPEN - File was opened
> 3. IN_CLOSE_WRITE - File was closed (and was open for writing)
> 4. IN_CLOSE_NOWRITE - File was closed (and was not open for writing)
> 5. IN_MOVED_FROM - File was moved away from a watched directory
> 6. IN_MOVED_TO - File was moved into a watched directory
>
> There is also the IN_UNMOUNT event. According to manual, kqueue has
> the NOTE_REVOKE event to signal that the underlying fileystem was
> unmounted, but I could not reach this behaviour. The fact that
> kqueue requires an open file descriptor per entry complicates the
> monitoring on removable devices.
>
> Inotify also provides an additional information for several
> notifications, i.e. for MOVED_FROM/MOVED_TO events it also supplies
> a name of the file moved. Technically for kqueue this information
> can be passed from kernel via kevent.data (if to consider this field
> as a pointer).
>
> Determining the possibility of extending kqueue with this additional
> functionality requires a deeper analysis, I have planned it on the
> community bonding period.
Solaris has Event Port interface, an equivalent of inotify, which has
mentioned capabilities. I would suggest to evaluate its interface:
http://blogs.sun.com/praks/entry/file_events_notification
(see man pages as well)
Having it in the kernel - might be something to consider. Also, AFAIK,
GIO already has support for it.
--
Mindaugas