Hi past-Y2k and pre-Y2038K folks !
Well, I think there are ways to progressively help developpers to switch to
Y2038. The main principle would be :
- let the kernel compute on 32 bits for now. Better for performance.
- glibc should return 64 bits results for each function return so that
if the result is interpreted as 64 bits, it's good, and if interpreted as
32 bits, it's still good till 2038-epsilon.
- glibc should accept as input 32 bits values for the moment so that inputs
from 64 bits are truncated to 32 bits to keep compatible with other 32 bits
apps.
- when glibc fills a structure, it should only write the 32 bits (act as
it's currently the case), but it would be to the 64-compliant apps to
initialize these structs to 0 before the first call to the system calls.
-> 32-bits code should still work
-> it would be possible to begin to develop 64 bits code, even if it is used
only as 32 bits for the moment. When we are ready to eliminate all the old
32 bits apps, then glibc could accept to work on true 64 bits data, keeping
the same interface and the kernel would use its new 64 bits counter,
transparently for glibc and apps.
it's obvious that this last step will break 32-bits software, at least for
structure-filling, but since this software will not be Y2038-compliant anymore,
what's the matter ?
Of course it's easy to say, but to do ...
Just my 2 cents.
Willy
-- Willy Tarreau - mailto:willy@meta-x.org - http://www-miaif.lip6.fr/willy/ System and Network Engineer at NOVECOM ( France ) - http://www.novecom.fr/ Magistere d'Informatique Appliquee de l'Ile de France ( MIAIF ), Year 1997- 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/
This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:05 EST