Re: More on bigger kdev_t

Jeff Garzik (jgarzik@pobox.com)
Fri, 08 Oct 1999 17:47:06 -0400


Andries.Brouwer@cwi.nl wrote:
> From jgarzik@pobox.com Fri Oct 8 21:27:18 1999
> This solution keeps most of userland, such as LILO, binary compatible.

> 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/