(No kernel expert here too)
Sorry for a delayed reply.
I think, instead of moving the time_t directly to 64 bits we
should do what intel did when they introduced 32 bit processors.
Keep AX,BX,CX etc but have them extended as EAX,EBX,ECX etc.
In the same way,if another 64 bit storage like time_t is created without
totally
scrapping the current 'time_t' then unchanged programs will continue to work
(at least till the d-date), while those requiring immediate changes can use
the
new 64 bit type.
We can have a longer time_t in time.h like : u64 l_time_t;
I do not know much about the kernel internals but,we can (can we ? ) map
the l_time_t such that its lower 32 bits coincide with those of time_t.
Incrementing l_time_t will automatically increment time_t and vice-versa
normally till 2038.
After that every program will _have to_ use the u64 variable.But things will
possibly go well for the next 32 complete years without any recompilation.
Using a union comes to mind,but a union will require '.' or '->' operator
to be used, which again invites recompilation.
Regards,
Pranav
--
______________________________________________________________________
Pune GNU/Linux Users Group Mailing List: (plug-mail@plug.org.in)
List Information: http://plug.org.in/mailing-list/listinfo/plug-mail
Send 'help' to [EMAIL PROTECTED] for mailing instructions.
