Re: On re-working the major/minor system

H. Peter Anvin
2001-12-07T22:05:34Z

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