Re: On re-working the major/minor system

Andries.Brouwer
2001-12-08T17:55:56Z

From: Erik Andersen <andersen@codepoet.org>

So we have POSIX, ls, tar, du, mknod, and mount and tons of other
apps all with illicit insider knowledge of what a dev_t looks
like.

To currently, to do pretty much anything nifty related to devices
in usespace, usespace has to peek under the kernel's skirt to
know how to change a major and minor number into a dev_t and/or
to sanely populate a struct stat.

To change things, we 1) need some sortof sane interface by which
userspace can refer sensibly to devices without resorting to evil
illicit macros and 2) we certainly need some sort of a static
mapping such that existing devices end up mapping to the same
thing they always did or 3) we will need a flag day where we say
that all pre-2.5.x created tarballs and user space apps are
declared broken...

No flag day required. These things have been discussed
many times already, and there are easy and good solutions.

Code like

dev_t dev;
u64 d = dev;
int major, minor;

if (d & ~0xffffffff) {
major = (d >> 32);
minor = (d & 0xffffffff);
} else if (d & ~0xffff) {
major = (d >> 16);
minor = (d & 0xffff);
} else {
major = (d >> 8);
minor = (d & 0xff);
}

will handle dev_t fine, regardless of whether it is 16, 32 or 64 bits.
You see that change of the size of dev_t does not change the values
of major and minor found in your tarballs.
We already use such code for isofs.

Andries