The ongoing device number debate [LWN.net]

There have been no new patches toward an expanded dev_t type for a week or two. The discussion goes on, however. Things do seem to be heading toward a conclusion as it becomes clear that the real issue is the scope of the changes to be made for 2.5.

The expansion of dev_t is uncontroversial; the only real point of discussion there is how big it should be. That will be Linus's call; he hinted a while back that he was changing his mind and prefered a 64-bit value (32 bits each for the major and minor number) over 32 bits with a 12:20 split. In more recent times he has been silent.

The real disagreement has to do with the form of the expanded dev_t patches, which implement something that looks very much like the old, static device number space. Some developers (well, one at least: Roman Zippel) complain that the patch should "go all the way" and create a fully dynamic number space. He cites numerous quotes from Chairman Linus, who favors a dynamic device numbering scheme, to support his point. (Linus, again, has been silent in the current discussion).

Unless he comes up with some impressive patches quickly, Roman looks likely to lose this argument. The focus of the work at the moment is to relieve an immediate, pressing problem: the lack of available device numbers. The problem is especially acute for SCSI disk drives, where the number of possible disks is too small, and they have been restricted to 16 partitions. A simple fix for this problem will make the people most concerned with dev_t expansion happy for now.

The bigger problem - the management of an entirely dynamic device number space - is still characterized by a paucity of working solutions. One approach (devfs) works, but it is a solution that is disliked by many. The most viable competing approach at the moment looks like the hotplug mechanism, which allows the kernel developers to push the entire problem into user space. Some promising work is being done in that area, but it is unlikely that even those closest to this work would claim that it will be ready for production deployment in the near future. There is also the little matter of the 2.5 feature freeze to worry about.

So a fully dynamic device number space looks like a 2.7 development. Few people contest the idea that a dynamic number space is, in the long run, a better way of doing things. But few people are ready to make that jump for 2.6.

(Log in to post comments)

The ongoing device number debate

Posted Apr 10, 2003 8:44 UTC (Thu) by brodders (guest, #5377) [Link]

Reserve major device top-bit now as dynamic hotplug?

Or major device 255.255.255.X space; methinks a dynamic X space with 256 majors could be more then enough.

I'll go back to sleep now.

?:^) brodders

The ongoing device number debate

Posted Apr 13, 2003 0:28 UTC (Sun) by mcelrath (guest, #8094) [Link]

Can someone post a link as to why devfs is so disliked? I've been using it for 3-odd years and it works fine, and is in my opinion a far more elegant solution than static device numbers. If we go to 32 or 64-bit numbers, will we have 2 billion /dev/sd* nodes? Static device allocation is just ugly. One should be able to look at /dev and figure out which devices are actually used...

-- Bob

The ongoing device number debate

Posted Apr 16, 2003 21:08 UTC (Wed) by Ross (subscriber, #4065) [Link]

For one thing, the idea of making a device node for only the things which are actually there doesn't work with all devices. Then there are dynamically loaded modules. If using a device node is what triggers module loading and if modules have to be loaded to create the device nodes then we have a problem.

The main reasons people don't like devfs are design issues:
1) The code is quite ugly, and misuses internal kernel interfaces. This breakage has made much of Al's cleanup work difficult.
2) The whole thing could be done in userspace.
3) It uses non-standard device names. While some of the changes are arguably an improvement, this should have been separated from the idea of a dynamic /dev.
4) Lots of people like the Solaris way better.
5) There are lots of race conditions in the code which don't hit people very often, but can cause disk corruption.
6) The mechanism which is used to remember changes in file permissions, etc. is ugly to say the least.