Subject: Re: 32 bit dev_t
To: Chris G. Demetriou <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 01/13/1998 11:17:48
> > * As an alternative to renumbering, you could instead make the minor
> > number non-contiguous; i.e.:
> > 3322222222221111111111
> > 10987654321098765432109876543210
> > |--minor---||--major---||minor-| new
> > |major-||minor-| old
Very Trick! :-)
> > * Given the above scheme, should we decide to renumber everything at
> > some point (hopefully only once!!!), we can simply choose some portion
> > of the major numbers (say, the first 256) and use them for
> > `compatibility'. There's no need to waste half the number space.
> So, I don't particularly like this because it makes device nodes much
> harder to 'read' as hex numbers, and it also means that our device
> nodes will look like those of no other system that i'm aware of.
> Neither of those are hard, technical objections.
> Also, if we're going to go to the trouble of making any change at all,
> I _do_ think it would be a good time to do the renumbering. (If we're
> going to renumber, why make the device nodes ugly, too?)
I think I now like the renumbering, and agree that we should do it w/
the 32-bit change.
Also, for compatability, how about we reserve the first 100 or so majors?
That way, we could quickly notice renumbered vs non-renumbered device
nodes (since it sounds cleanest for the kernel to always use 32-bit
dev_t's when it cares, as Charles suggested).
My thought is that major 0 is the magic its-a-16-bit-dev_t major. Any other
reserved ones (say 1 to 99) are just reserved as a policy decision, to
help the transition. If/when we run out of majors, we can start using these