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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Dec 07 2001 - 21:00:40 EST