One of the things that has been on the 2.5 "to do" list since before there
a 2.5 is expanding the dev_t
type to 32 bits.
, of course, is currently a 16-bit value holding the
eight-bit major and minor device numbers. The small size of the device
number fields has been a constraining factor for people building systems
with thousands of devices for some time; it had been pretty well assumed
that it would be expanded in this development cycle.
Almost three months into the feature freeze, the dev_t expansion
is nowhere in sight. It remains necessary, however; consider this statement from Alan Cox:
32bit dev_t IMHO is essential to 2.6. Essential enough that if its
not in the base 2.6 all the vendors have to get together and issue
a Linus incompatible but common 32bit dev_t interface.
32-bit dev_t as an added vendor patch would make for a big
difference between the Linus kernel tree and that which is shipped by the
distributors. But large distributor patches to the kernel are not that
uncommon. The real issue here is that no 32-bit dev_t patch has
been posted - whether for integration or not.
Expanding dev_t is not a trivial task. The interface with user
space must be handled carefully to avoid breaking older applications. The
kernel currently tracks devices through the static blkdevs and
chrdevs arrays, which are indexed by the major device number.
This approach works when there are only 256 possible device numbers, but
falls apart when you can have thousands of them. And, despite a
continued effort to stamp them out, there are, beyond doubt, many places in
the kernel which assume implicitly that device numbers are eight bits
So the dev_t expansion will be somewhat invasive and
destabilizing - though certainly achievable. It really should happen
sooner rather than later. If it is
true that a larger dev_t will be a part of the 2.6 kernel actually
seen by customers, then this work is one of the factors which is delaying
the 2.6 release.
to post comments)