What ever happened to 32-bit dev_t?

One of the things that has been on the 2.5 "to do" list since before there was a 2.5 is expanding the dev_t type to 32 bits. dev_t, 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:

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 wide.

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.

---

(Log in to post comments)