Add kqueue support to GIO

What is the goal of the project?

The goal of the project is to add kqueue support to GIO. GIO, the Glib IO layer, currently uses inotify interface to monitor changes in the filesystem, so it does work on Linux and does not work on NetBSD. The importance of the file monitoring grows with the evolution of modern desktop environments. Semantic desktops, local file indexers and even usual file managers, such as Nautilus, use it to provide an updated information to user. GIO is used in many applications, and providing a full-featured file monitoring to it will significantly increase the end-user convenience as well as application compatibility.

File system notifications are important on servers as well. It is used by Mediatomb; it is also used by some administrative tools like lsyncd, iwatch and probably Samba.

This aspect imposes some constraints on the kqueue backend and the emulation layer - it should be more fast and more reliable.

If the time will permit (I assume it will), it would be also possible to implement an userspace library that will emulate the inotify interface on the top of kqueue. It will help applications that do not use GIO but use inotify directly.


What will be the deliverables of the project?

In the form in which I see the project, the final deliverables are expected to be:

1. A set of patches for GIO. A big refactoring is expected, so it will be discussed with the original GIO developers before. In the worst case, if the changes will not be accepted to the upstream, it is possible to keep custom patches for pkgsrc.
2. Userspace inotify-over-kqueue library sources [probably]. Distributing the inotify emulation library as a separate package is flexible - it makes this library optional and users may choose, to install it or not to install. Also, distributing the library as a package makes it easier to spread across other BSDs (its representatives have already interested in this project on the mailing list). pkgsrc allows to integrate such compatibility things easily in the system.
3. Documentation files describing general design decisions;
4. A set of sample programs to ensure that is the introduced functionality does work (tests).

Milestones and schedule

1. Community bonding period
• Getting familiar with GIO file monitoring implementation;
• Researching the way to isolate it from inotify;
• Probably studying kqueue/inotify implementations on the kernel side;
• Discussing the ways of implementation with the mentor;
2. May 23 - June 23: the core work
• Isolating GIO from inotify with a compile-time abstration level;
• Implementing the kqueue backend;
• Interim testing and reviews;
3. June 24 - July 10: wrap up for this milestone
• Reviews;
• Bug fixes;
• Tests;
4. July 11 - August 1: the rest of the work
• Implementing the user-space inotify interface over kqueue;
• Interim testing and reviews;
5. August 2 - August 7: offline
• Probably I will miss this days;
6. August 8 - August 22: final stage
• Reviews;
• Bug fixes;
• Tests;
• Delivery.

Implementation notes

The abstraction layer for GIO will be implemented as a compile-time Strategy pattern.

There is a tricky moment with inotify-over-kqueue emulation. The problem is that inotify provides some types of notifications that kqueue does not - i.e. IN_MOVED_FROM/IN_MOVED_TO with the additional
information and so on. For it I am going to use the standard file system routines such as readdir(), stat()  and so on.

However the frequent usage of these system calls will result in a negative impact on the performance, so  I consider the possibility to extend kqueue to support additional events.

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.


About me

My name is Dmitry Matveev; I am a 5th year student of Nizhny Novgorod State Technical University, Russia.

I use NetBSD for an year, it is the primary OS on my home laptop and I am completely happy with it.

I have been working as a VoIP programmer since 2008 and left it in 2010. It is 2+ years of strong enterprise programming experience on C, C++ for embedded platforms, such as VxWorks and WinMobile. We have used SVN for source control, currently I am enjoying git for it.

Besides C and C++, I have studied Smalltalk and Common Lisp for fun. I think that it allows to see a problem under different points of view and pick a solution in the most appropriate way with any language. It is always good.

In 2010-2011 I have completed a course of Linux system programming by Auriga, where we have studied Linux kernel basics and general OS development concepts. Currently I am continuing studying this sphere by myself.

Regarding my NetBSD experience, I have been working on GNU Smalltalk to make it work well on NetBSD. Within this activity I have discovered a bug in the NetBSD kernel and proposed a fix:

    http://mail-index.netbsd.org/tech-net/2011/02/17/msg002457.html

Also recently I have started a tech blog and NetBSD is the one of the major topics there:

    http://dmitrymatveev.co.uk/blog?tag=netbsd