Andries Brouwer released a new set of patches this week which brings the
long-planned expansion of dev_t
closer to reality. These patches
rework the character device infrastructure to make it safe for much larger
numbers of devices. For now, at least, it is not even necessary to change
any char drivers to work properly with the new code.
The first patch clears out the char device
code within the filesystem area. This code included a whole structure for
tracking devices, managing reference counts, etc. That structure was only
used in one place, however, and Andries decided that, rather than fix it up
to work with larger device numbers, he would just hack it out altogether.
The rest of the kernel will not really notice its absence, for now.
The core of the work is in the second
patch. Here, the longstanding static chrdevs array is
removed. A static array of devices works reasonably well when there is a
maximum of 255 of them; it's rather less convenient when there can be
thousands of device numbers. In its place is a simple hash table with
linked lists of registered char drivers.
There is a new way of registering a char driver:
int register_chrdev_region(unsigned int major,
unsigned int baseminor,
const char *name,
struct file_operations *fops);
The new baseminor and minorct arguments describe the
range of minor numbers that the driver is prepared to deal with. Char
drivers should eventually be converted to the new interface, but there is
no great hurry; the register_chrdev() interface is still supported
int register_chrdev(unsigned int major, const char *name,
struct file_operations *fops)
return register_chrdev_region(major, 0, 256, name, fops);
So unchanged char drivers will still work, and will not be confronted with
minor numbers greater than 255.
For now, drivers requesting a dynamic major number may continue to use the
same mechanism: passing major as zero. The mechanism implemented
in the patch is not entirely robust, however, and is marked as being
The third patch just cleans things up a bit,
and removes the MAX_CHRDEV macro. For the truly adventurous,
there is a fourth patch which actually
changes dev_t to 32 bits, using a 16:16 split.
These patches have found their way into the -mm kernel tree, and are now in
need of some serious testing. Should things work out, the 32-bit
dev_t expansion may finally get crossed off the 2.5 development
to post comments)