Re: More on bigger kdev_t

Theodore Y. Ts'o (tytso@mit.edu)
Sat, 9 Oct 1999 10:56:07 -0400

I would suggest introducing kdev_t as a structure (and not as a pointer
to a structure) for one reason --- it makes attempts to do any kind of
mathematical or logical operations on a kdev_t painfully obvious. With
a pointer, you get a warning, but with a structure, you get compiler
error that's impossible to ignore. Given that any attempt to treat a
kdev_t in that way is a bug, you might as well have the kernel detect it
for you anyway.

If kdev_t is a 4 byte long structure, (i.e., using a 16/16 major/minor
split), the compiler should be able to do a relatively good job of
optimizing accesses to it. If not, that's a compiler bug that we should
report, and ask the gcc/egcs folks to fix.

In any case, the whole point of kdev.h is that we can easily change the
representation of kdev_t without having to touch the rest of the kernel.
We can do kernel profiles, and if it turns out to be a real performance
problem, we can change the representation later. And of course, any
interfaces to userland (or to get ROOTDEV from the boot blocks, etc.)
should be done via the accessor functions (or cpp macros) found in
kdev.h.

I wouldn't bother changing the boot block ROOTDEV representation, BTW.
Limiting the root device to have major/minor numbers less than 256 seems
to be a quite reasonable limitation, at least for now.

- Ted

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/