Re: On re-working the major/minor system

[Andries.Brouwer@cwi.nl]

    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