Linus Torvalds wrote:
>
> And let's take a look at /dev. Do a "ls -l /dev" and think about it. Every
> device needs a unique number. Do you ever envision seeing that "ls -l"
> taking about 500 billion years to complete? I don't. I don't think you do.
> But that's how ludicrous a 64-bit device number is.
>
That's how ludicrous a *dense* 64-bit device number is. I have to say I
disagree with you that sparse number spaces are a bad idea. The
IPv4->IPv6 transition people have looked at the issues of number spaces
and how much harder they get to keep dense when the size of the
numberspace grows, because your lookup operation becomes so much more
painful. Any time you have to take a larger number space and squeeze it
into a smaller number space, you get some serious pain.
Part of the reason we haven't -- quite -- run out of 8-bit majors yet is
because I have been an absolute *bastard* with registrants lately. It
would cut down on my workload if I could assign majors without worrying
too much about whether or not that particular driver is really going to
be made public.
64 bits is obviously excessive, but I really don't feel comfortable
saying that only 12 bits of major is sufficient. 16 I would buy, but I
don't think 16 bits of minor is sufficient. Given that, it seems to me
-- especially since dev_t isn't exactly the most accessed data type in
the universe -- that the conceptual simplicity of keeping the major and
minor separate in individual 32-bit words really is just as well. YES,
it's overengineering, but the cost is very small; the cost of
underengineering is having to go through yet another painful transition.
Unfortunately, the Linux community seems to have some serious problems
with getting system-wide transitions to happen, especially the ones that
involve ABI changes. This needs to be taken into account.
-hpa
-- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/