lkml.org 
[lkml]   [1996]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: libc types [was: SCSI device numbering]
Stephen C. Tweedie:

:: Just do it already! :-) If we need a new fs type
:: like ext3, then LET'S GET ON WITH IT! Sheesh! :-)

: Easy to do. Dead easy. Trivial, a two-liner, not worth losing sleep
: over.

I am afraid the kernel patch is larger - with a 48-bit minor,
one can no longer use the minor to index arrays, for example.

: We've talked about this before. The trouble is that it is NOT a
: filesystem issue, it's a kernel/libc API issue, and _that_ is tricky.
: Nobody has yet been brave enough to tackle it.

: Think about it. We need a new mknod(), new stat(), basically
: replacing every system call which uses a 16bit dev_t. We need a new
: libc which incorporates the new dev_t. _Then_ we need to recompile
: every binary on your entire system which looks at dev_t. And the hard
: part is that you need to do it in such a way that every possible
: combination of 16/64bit libc and kernel work perfectly.

: This is not an impossible task, but it's ugly. What we really need is
: to synchronise libc and kernel updates for this kind of change.
: libc-6 and linux-2.2, say. The kernel will have to provide the older,
: short-dev ABI for a long time, but we can still mandate that the new
: libc requires a newer kernel.

Not so pessimistic. I plan to submit a series of patches to the kernel
so that it (i) gets a kdev_t that is a pointer to a structure,
(ii) gets new, versioned, stat and mknod system calls,
(iii) learns about a new struct stat, with larger dev_t,
where all of this works with the current libc.
[I have been running such a patched system already since 1.3.20 or so.]
When the kernel is ready, libc can be changed, also in such a way
that the new libc also works for old kernels.
Things have to be done slowly and carefully, but I see no ugliness.

Maybe you are interested in another change to struct stat as well:
off_t st_size;
allows only 2GB files (according to POSIX off_t is a signed type)
- not very much. On http://www.sas.com/standards/ under
`Large File Summit' a transition to larger file sizes is discussed.
Probably Linux should go the same way as Sun and several others.
Such a change might or might not be done simultaneous with the
change for a larger dev_t.

Andries





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