lkml.org 
[lkml]   [1999]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.196 / U:0.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site