Re: On re-working the major/minor system

[Erik Andersen]

On Fri Dec 07, 2001 at 02:04:42PM -0800, H. Peter Anvin wrote:
> 
> It's clear a painful change is needed.  **We don't have a choice.**
> However, the fewer places we have to make source code changes the better.

Sure.  I'm not arguing again the change.  Just making sure
everyone 100% understands that we have just thown any prayer of
binary compatibility with anything less then 2.5.x....

But lets look on the bright side though.  Since we are going to
be having a flag day _anyways_ we may as well make the most of
it.  I can think of 20 things off the top of my head that are
being retained in the name of binary cmpatibilty that can easily
move to the trash bucket.  :)

For example, I would _love_ for Linux to standardize syscall
numbers across all architectures, guarantee that userspace gets
the exact same stack setup for all arches, we might as well fixup
proc, etc, etc, etc.

> What we agreed upon when this was discussed last year was the following:
> 
> dev_t is extended to a 12:20 (32-bit size.)  I personally would rather
> have seen a 64-bit size (32:32) but was outvoted :(
> 
> New major 0 is reserved, except that dev_t == 0 remains the code for "no
> device".  The unnamed device major becomes major 256.
> 
> If (dev_t & ~0xFFFF) == 0, the dev_t is interpreted as an old-format
> dev_t, and is interpreted according to the following algorithm:
> 
> 	if ( dev && (dev & ~0xFFFF) == 0 ) {
> 		major = (dev >> 8) ? (dev >> 8) : 256;
> 		minor = dev & 0xFF;
> 	} else {
> 		major = dev >> 20;
> 		minor = dev & 0xFFFFF;
> 	}

That works, and should prevent most major problems.  Hmm.  At
least for cpio there are 6 chars worth of device info in there,
so we coule easily go to 48 bits without RPM problems.  Or redhat
could fix rpm to use tarballs like debs do, and then we could go
to 64 bit devices no problem.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--