kdev_t is no more [LWN.net]

Al Viro's second set of patches aimed at enabling the support of a larger dev_t type has been merged into the 2.6.0-test5 kernel. The bulk of the work is fixing up code in filesystems which made assumptions about the size of dev_t. As part of this whole process, however, Al has been converting kernel code from the kdev_t type over to using dev_t directly.

kdev_t, of course, was introduced several major releases ago as a way of hiding the actual structure of device numbers. The comments in <linux/kdev_t.h> read:

As a preparation for the introduction of larger device numbers, we introduce a type kdev_t to hold them. No information about this type is known outside of this include file.

In practice it didn't work quite that way. When Linus changed the format of kdev_t early in the 2.5 development series, everything broke. And when the time came to really change the size of dev_t, it turned out to be easier and more clear to simply use dev_t directly. Kernel hackers tend to be skeptical of abstraction interfaces which are created without being immediately useful; kdev_t is an example of why that is so.

The seventh patch (of 15) in Al Viro's second dev_t series changes the type of the much-used i_rdev inode structure field; it is, of course, a dev_t now. Since Al had already converted users of that field over to the new iminor() and imajor() macros, the effect of this change was small. But, as it turns out, i_rdev was the last kdev_t object in the kernel. So patch eight removed the type altogether.

Out-of-tree drivers will, of course, be broken as a result of this change, but the fixes should not be that difficult. At this point, the bulk of the large dev_t preparation work should be done. About all that's left is to decide what the format of the new dev_t will really be and make the change. Once the dust settles, another one of the 2.6.0 "must fix" items will have been taken care of.