Re: HEADS UP! MAJOR change to FreeBSD/sparc64

On Sunday 14 March 2004 08:12 pm, Garance A Drosihn wrote:
> In the case of i386, there is a 10-year history of servers and
> programs running with 32-bTT, in production.  I do also run
> freebsd/i386, and for that platform I really can not imagine making
> this major a change without providing backward-compatibility.  There
> is just too much written which assumes 32-bTT, including programs
> which perhaps can not be recompiled.  I do not see that happening
> before the 6.0-branch.

FWIW, 64-bTT on i386 is something I've been playing with some in my spare 
time, and IMHO it's an even bigger headache than on sparc64.  The ABI 
compatibility thing itself isn't a huge issue -- there are a couple of 
approaches involving compatibility syscalls / libc hacks.  Not exactly 
trivial, but it's doable.

The biggest problem on i386 is that there's a lot of third party software out 
there that misbehaves if sizeof(time_t) > sizeof(long), even when recompiled 
from source.  I don't think this an issue on sparc64/amd64 -- IIRC long is 
already 64 bits on those platforms.  Only real solutions I can think of at 
the moment are:

1. Go 64-bit for longs on i386.  I've seen scattered murmurings that this is 
possible with the current sources and a few folks run systems this way.  I'm 
pretty sure there's no way to do this without completely breaking the ABI.  
Maybe if it coincided with a major libc version bump, and a compat ABI in the 
kernel, with new ELF branding for the 64-bit binaries...  Maybe.  It could 
also have an appreciable performance hit, though those who have been 
experimenting with it would know more than I how severe it is.

2. Bite the bullet and fix all the broken software.  This is probably the 
'correct' approach.  I don't know exactly which specs (POSIX? C99?) apply, 
but I'm under the impression that no guarantee is made about the size of 
time_t relative to other basic types.  If someone knows for sure, please 
correct me.  This means lots and lots and lots of patches in the ports tree.  
Even with submitting them back, quite a few would have to be held locally as 
some authors may not care to fix it until Linux does the same thing and 
forces the issue.  As a workaround, maybe there could be a flag in ports for 
'64-bit time_t clean'.  If it's not set, some magic could kick in and build 
the port with a 32-bit time_t (activating whatever compat mechanism we have 
in place for old binaries).

3. Do nothing on i386.  Everybody should have a shiny new ÜberHammer 256-bit 
CPU by 2038, right? ;-)

Craig