> But kdev_t is kernel-internal.
> Whatever the kernel chooses is completely invisible
> for user space. Its identity is hidden inside kdev_t.h,
> even the rest of the kernel doesn't know.
>
> If I boot a kernel on Friday, kdev_t is a pointer to a structure,
> on the other days it is a 32-bit integer.
> *Nothing* in userland depends on kdev_t.
Technical true, but changing it DOES affect userland: there is still
code which assumes things about the size of major/minor numbers. Look
at the assignment of ROOT_DEV in the various architectures.
> Yes. And making kdev_t a pointer to a structure is just as easy.
Making kdev_t a structure is obviously the eventual, and best solution.
But I disagree that making it a pointer is the easiest thing to do, or
that another large array is the way to go. By keeping kdev_t an lvalue
you make it easier to update current code which doesn't use kdev_t.h
macros, or is in some other way "hairy".
Or to put it another way, keeping kdev_t an lvalue is the quickest
method to get me to the end result of larger major/minor numbers.
Regards,
Jeff
-- Custom driver development | Never worry about theory as long Open source programming | as the machinery does what it's | supposed to do. -- R. A. Heinlein- 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/