Kernel development

Kernel release status

The 2.6.13-rc1 kernel was released on Jun 28. It contained over 2000 different patches, showing that there was a lot of pent-up development during the end of the 2.6.12 release cycle. It contains changes in almost all areas of the kernel, such as: USB, SCSI, driver core, ALSA, static cleanups, IDE, network drivers, network core, audit, input, pcmcia, I2C, W1, V4L, NFS, IB and ARM arch. It also contains some new features such as kexec/kdump, execute-in-place and a new architecture called xtensa. Also, devfs has been disabled from the build (but the code is still present). In all, over 3000 files were changed, with over 190000 lines added and over 84000 lines removed.

Since then, the 2.6.13-rc2 kernel was released on July 5. It had a much more manageable set of around 180 patches. The patches were mostly bug fixes for various things that were merged in the 2.6.13-rc1 release: driver core, PCI, ARM, TCP, pcmcia and serial, along with a few new options: driver binding and unbinding from userspace through sysfs.

The current stable 2.6 kernel is 2.6.12.2, it was released on July 1.

Linux 2.4.32-pre1 was released on July 4, it contains x86_64 security updates and other fixes.

Comments (4 posted)

A couple of graphical git front ends

The development of git is a classic free software success story, even at this early stage. When Linus Torvalds needed a new tool for managing source code revisions, he sat down for a week and bashed out something which was enough for other people to play with. It didn't do much, but it contained enough in the way of good ideas and functionality that a group of developers quickly gathered around it and started making it better. Git may still have a number of rough edges, but, to a great extent, it has taken BitKeeper's place in the development process.

One of those rough edges has been the lack of graphical tools for working with the repository. Things are happening in this area as well, however, and there are now two tools available which warrant a look. These tools (being gitk and qgit) both function as patch browsers; neither, currently, can actually make any changes to a git repository. In other words, capabilities like three-way patch conflict resolution are still missing. But you have to start somewhere; either of these tools will be helpful for anybody who wishes to look at the path the kernel took to get to the current point.

gitk is a Tk-based utility written by Paul Mackerras; the current release is version 1.1. The build process for gitk is about the easiest your editor has ever encountered; since it is written in Tcl, installation is simply a matter of putting the gitk script somewhere in your path.

Running gitk yields a three-paned window. At the top is a reverse-time list of committed patches, along with a graphical trace showing which tree each patch was merged from. Tags in the repository are indicated by a cute little yellow tag in this pane. The bottom left shows the selected patch in a fairly gaudy, colorful form. The commit text and the patch itself are run together, just as they would appear in an emailed patch. On the lower right is a list of files touched by the current patch; clicking on the name of a file narrows the view to the corresponding portion of the patch.

There is a simple "find" function which can search for patches whose description or author information match a given string; searching with regular expressions is possible. If you know the SHA tag for a given commit, you can type (or paste, presumably) it into a blank and view the corresponding patch. gitk also stores the SHA ID of the current commit in the X selection, allowing it to be pasted into git commands if need be.

The alternative to gitk is qgit, a Qt-based application currently at version 0.6. The initial experience with qgit is a little rougher; the application uses SCons for building instead of make. Since most systems tend not to have SCons installed, the qgit tarball includes a prebuilt version of SCons and a script to hack up the build file to use it. One thinks that, for a relatively simple application, it might have been easier to just toss in a makefile.

The initial qgit window looks very similar to gitk. The lower left pane shows only the commit text, however; the actual patch is nowhere to be seen. A single click on the filenames on the right appears to do nothing; a double click will pop up a separate window with the full text of the file. It turns out that one has to double-click on the appropriate line in the top pane to get a separate window with the patch itself. Once the window is up, it will be updated with the body of any patch selected in the main window. The presentation of the patches is a bit nicer than in gitk; the use of color is a bit more restrained, and patches are shown in the diff -up format that developers are used to reading. The patch window, however, has the obnoxious feature that it is permanently on top of any other window on the screen, regardless of the user's desires.

Nicely, in version 0.6, the qgit file browser window includes line-by-line annotation which makes it easy to figure out which commit modified a specific piece of code. This feature is enough to make one wish that the kernel.org git repository contained more than a few months of history.

qgit also makes it possible to search for specific patches; entering a string in the blank and clicking "filter" will narrow the patch view to the patches containing the string. It is not obvious, but the way back to the full listing is to hit "filter" again.

Once upon a time, your editor asked the BitKeeper folks how to determine which tree was the source of any particular changeset in the mainline. The answer that came back was that this information was not available - BitKeeper did not store it. So it is pleasing to see this information so readily in evidence in either git front end. We really do have a better handle on the development history than we did even a few months ago.

Both tools can be a bit rough to use at times, and their features are limited. When one considers that, back at the beginning of March, none of this software existed at all, it is hard not to be impressed. There is a lot happening around git, and, chances are, we've just barely seen the beginning of it.

Comments (3 posted)

Looking at inotify again

In September, 2004, LWN.net took a look at the inotify patch. This patch has been reworked a number of times by its primary developers, and has been living in the -mm kernel tree for a few months. With the recent What to merge for 2.6.13? discussion, inotify was mentioned as something that might be considered for merging into the main kernel tree. One thing that few kernel developers had paid attention to in the inotify patch was the userspace interface to the feature. So, let's take a look at how a programmer is supposed to interact with inotify.

From the documentation included in the kernel patch, inotify communicates to userspace through a character device, /dev/inotify. This is a misc character device (it uses the misc_register() kernel interface to create its character device), and if you use udev to manage /dev, the device node is automatically created. If not, the character node needs to be created by hand:

	mknod /dev/inotify c 10 63

Inotify works with something called "watches". A "watch" is an object and a mask that describe an event that the user wants to receive notification events from. The object is either a file or a directory, as represented by an open file descriptor, and the mask is a bitmask of events. The different types of events that can be monitored are:

	IN_ACCESS		The file was accessed
	IN_MODIFY		The file was modified
	IN_ATTRIB		The metadata changed
	IN_CLOSE_WRITE		The writtable file was closed
	IN_CLOSE_NOWRITE	The unwrittable file closed
	IN_OPEN			The file was opened
	IN_MOVED_FROM		The file was moved from location X
	IN_MOVED_TO		The file was moved to location Y
	IN_CREATE		A subfile was created
	IN_DELETE		A subfile was deleted
	IN_DELETE_SELF		self was deleted

If the user wants to monitor all events, a handy IN_ALL_EVENTS macro is defined which includes all of the above event flags combined together. To create a watch and register it with the kernel, an ioctl is called on the /dev/inotify node:

	struct inotify_request request = { fd, mask };
	int watch_desc = ioctl(dev_fd, INOTIFY_WATCH, &request);

where fd is the open file descriptor of the file or directory you wish to watch, and mask is the type of event to monitor. To remove a watch that is already in place, another ioctl should be sent:

	ioctl(dev_fd, INOTIFY_IGNORE, watch_desc);

Once a watch has been registered with the kernel, a simple read() call to the device node is used to retrieve events based on that watch (and all other watches that have been registered for this process.) The structure of the data that read from the kernel is described in the following C struct:

struct inotify_event {
	__s32	wd;		/* watch descriptor */
	__u32	mask;		/* watch mask */
	__u32	cookie;		/* cookie to synchronize two events */
	__u32	len;		/* length (including nulls) of name */
	char	name[0];	/* stub for possible name */
};

All of the fields are pretty self explanatory, with the exception of "cookie". If this field is not set to 0, then it is used to tell userspace that multiple events happened at the same time on the same object. An example of this is renaming a file. If a directory is being watched and the following file rename happens in it:

	mv foo baz

there would be 2 events generated, an IN_MOVE_FROM and an IN_MOVE_TO event. They would both have the same cookie value, which allows userspace to coordinate the events. The /dev/inotify node allows select() and poll() to be called on it, so a blocking read() is not necessary, which would tie up a program's thread.

The FIONREAD ioctl is also supported by inotify, and returns the size of the current pending event queue, if userspace wishes to do dynamic buffer allocation to place the events into. When the userspace program that had the /dev/inotify node open exits, or when the node is closed, all watches that were registered with the kernel are destroyed and cleaned up properly.

For a very simple example program that shows how to register for events, and read events as they happen, see the inotify-utils package that can be found here.

For more details on the kernel design decisions that the inotify developers went through in creating this system, please see the inotify documentation in the kernel patch. It describes why a character node was used instead of signals, and other details.

Comments (14 posted)