I made a pre6, which contains a new-and-anal "kdev_t".
The format of the thing is the same as it used to be, ie 16 bits of
information, but I made it a structure so that you _couldn't_ mix up
"dev_t" and "kdev_t", or use the "kdev_t" as a number (so when kdev_t
expands to 12+20 bits later in 2.5.x you shouldn't get surprises)
I fixed up the stuff I use and which showed up in compiles (on a source
level, it's so far totally untested), but I'd really like people to check
out their own subsystems. _Especially_ NFS and NFSD, which had several
cases of mixing the two dev_t's around, and which also used them as
numbers. Trond, Neil?
Because the types aren't at all compatible any more, the macros that are
used for user-level "dev_t" are no longer working for a kdev_t. So we have
dev_t kdev_t
MKDEV(major,minor) mk_kdev(major, minor)
MAJOR(dev) major(dev)
MINOR(dev) minor(dev)
dev == dev2 kdev_same(dev, dev2)
!dev kdev_none(dev)
and _most_ of the time the fixes are trivial - just translate as above. It
only gets interesting when you have code that looks at the value or starts
mixing the two and compares a "dev_t" against a "kdev_t", which can be
quite interesting.
The knfsd file handle thing is also an issue - Neil, please check out that
what I did looks sane, and would be on-the-wire-compatible with the old
behaviour, even when we expand kdev_t to 12+20 bits, ok?
(Marcelo, for easier backporting of drivers to 2.4.x, we'll probably want
to eventually add
#define mk_kdev(a,b) MKDEV(a,b)
#define major(d) MAJOR(d)
...
to the 2.4.x <linux/kdev_t.h> so that you can move drivers back and
forth).
Apart from some knfsd issues, most of the kdev_t users were proper. The
strict type-checking found one bug in the SCSI layer (which I knew about,
and was one of the impetuses for doing it in the first place), and found a
lot of small "works-but-will-break-with-a-bigger-kdev_t" issues).
Linus
> I made a pre6, which contains a new-and-anal "kdev_t".
Nice! And even in my original form, with these heavy kdev_same
and kdev_none things :-).
I booted a kernel but had quite a lot to change, the patch
is large. I can send it, but instead:
(i) I changed almost every single MKDEV to mk_kdev.
Of course, the kernel was rather kdev_t clean, it was
not difficult to run with kdev_t a different type, so
there are very few places where this is inappropriate,
and the number of correct places is so large that a
global command, followed by a revert in these very few
places, seems more appropriate than a large patch.
Moreover, probably you and others did part of this already.
Not to be changed:
./init/do_mounts.c: sys_mknod("/dev/console", S_IFCHR|0600, MKDEV(TTYAUX_MAJOR, 1));
./arch/sparc64/solaris/fs.c: sys_mknod((const char *)A(path), mode, MKDEV(major,minor));
./include/linux/kdev_t.h
All else should be changed (or at least: did I change, I may have
overlooked sth).
In do_mounts.c there is a real_root_dev set via /proc, and I left it
an integer, while ROOT_DEV is a kdev_t, which implies the
appropriate conversions there.
(ii) Then there are MAJOR and MINOR. I did not change these to
major and minor, mainly because in some possible futures
it will be necessary to do a lot of grepping for these again -
almost all occurrences should be removed - and major and minor
are such common words. It is nicer to have something more unique,
like kmajor and kminor. Moreover, major and minor do at present
also occur as ordinary variables.
Are kmajor, kminor acceptable?
Andries