kdev_t is no more
[Posted September 10, 2003 by corbet]
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.
(
Log in to post comments)