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
to post comments)