Messages in this thread | | | Date | Sat, 9 Oct 1999 19:59:48 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: More on bigger kdev_t |
| |
Date: Sat, 09 Oct 1999 16:24:02 -0700 From: Zack Weinberg <zack@bitmover.com>
... so that would mean we should use a pointer to the structure instead of directly passing the structure.
I just don't want to see us have to transition userland twice.
There shouldn't be any userland transition when we change kdev_t. kdev_t is an internal abstraction known only to the kernel.
What will require a userland transition is when we change dev_t, which is the exported interface to userland of the major/minor device number. Fortunately, glibc is already ready for us; dev_t is a 64-bit long long. So it's only a matter of updating new system calls which reference dev_t, which are relatively small. mknod() and stat() are the to main ones which come to mind. So we simply add new versions of those two system calls which use the 64-bit version of dev_t, and then the next glibc update will try to see if the new system calls exist, and if not, fall back to the old system calls for backwards compatibility with older kernels.
This change has *nothing* to do with the internal representation of kdev_t. kdev_t may be a pointer to a structure, but that doesn't mean anything about what dev_t is. Indeed, the two changes are completely orthogonal to each other. We can update dev_t to use 64 bits independent of changing kdev_t.
Of course, we won't get the advantages of using greater than 8 bit major/minor numbers until we do both, but they don't have to be done at the same time.
- 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/
| |