> 
> > * 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
reserved nodes.

Take care,

Bill