Re: On re-working the major/minor system

[H. Peter Anvin]

Erik Andersen wrote:

> 
> Ok, so we go through, change sys/sysmacros.h, tar.h, cpio.h, and
> any other offending header file.  And guess what?  Not only has
> nothing changed (since those are macros, not functions), but you
> just broke every older .deb and .rpm in existance on your updated
> system.
> 
> In sys/sysmacros.h it defines major() and minor() as macros, so
> just dropping in an updated C library binary isn't going to do
> squat until all of userspace gets recompiled.  And tar.h and
> cpio.h define long standing (well over 10 years now) binary
> structures.  We can't just go changing this stuff, since now when
> a dev_t is some magic cookie, if I go to install something from
> my old Debian 1.2 CD or my old RedHat 4.0 CD, my system will puke
> trying to install using cookies that in fact are old 8/8 split
> device nodes and not cookies at all.
> 

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.

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;
	}

	-hpa