dev_t expansion status [LWN.net]

The expansion of the dev_t type to 64 bits has been stalled for a few months now. Most of the work, it seems, has been done, but the patches have yet to find their way into the mainline kernel. Among other things, the dev_t expansion has been held up waiting for another set of patches from the elusive Alexander Viro. Mr. Viro still only surfaces rarely on the mailing lists, but it seems he has been busy; a set of large dev_t patches has turned up in 2.6.0-test4-mm2.

Many of the patches are essentially cleanups, such as removals of final uses of the kdev_t type which can be replaced with something else. After all, if a piece of code does not use device numbers at all, it should not run into trouble if the size of those numbers changes. Others begin to address more problematic code; for example, the JFFS filesystem incorporates device numbers directly into its on-media data structures; a change in the device number size would make older filesystems unreadable. In this case, for now, the (16-bit) size of this field has been made explicit.

Some of the patches take care of some (seemingly) unrelated block device layer cleanups. A few things, it seems, didn't work quite as well as expected once Al went back and took another serious look at the code.

Then, there is a simple addition to <linux/fs.h>:

	static inline unsigned iminor(struct inode *inode)
	{
		return minor(inode->i_rdev);
	}

This little function is the subject of the largest patch in the series: it replaces references to inode->i_rdev in a vast number of drivers and a few filesystems as well. The purpose, of course, is to allow access to the minor number of the device behind an inode without requiring any knowledge of how that number is actually stored within the inode. Not surprisingly, there is also an imajor() helper function.

Al mentions another series of patches which have not yet made an appearance. They will include a change to the inode structure, turning the i_rdev field into a dev_t type (from kdev_t). At that point, the addition of all those iminor() and imajor() calls will make sense; code using those calls will be unaffected by the inode structure change. There will also be patches to ensure that the conversion of device numbers between the internal representation and that used on-disk by filesystems is done properly.

So the expanded dev_t project is moving forward once again. This is an important feature to have in 2.6, so this is a good thing. There is, however, a large set of fairly invasive patches coming which may bring a surprise or two when it hits the 2.6.0-test mainline. (The actual patches can be seen in the 2.6.0-test4-mm2 patch, or separately on kernel.org; a good place to start is Al's overview of the patch series).