Date: Sun, 14 Mar 2004 23:17:09 -0600 From: Craig Boston <craig@xfoil.gank.org> To: freebsd-current@freebsd.org Cc: Stephen McKay <smckay@internode.on.net> Subject: Re: HEADS UP! MAJOR change to FreeBSD/sparc64 Message-ID: <200403142317.09065.craig@xfoil.gank.org> In-Reply-To: <p06020404bc7abad600b6@[128.113.24.47]> References: <p060204f5bc750679b827@[128.113.24.47]> <200403140716.i2E7GDKa007204@dungeon.home> <p06020404bc7abad600b6@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
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. =46WIW, 64-bTT on i386 is something I've been playing with some in my spare= =20 time, and IMHO it's an even bigger headache than on sparc64. The ABI=20 compatibility thing itself isn't a huge issue -- there are a couple of=20 approaches involving compatibility syscalls / libc hacks. Not exactly=20 trivial, but it's doable. The biggest problem on i386 is that there's a lot of third party software o= ut=20 there that misbehaves if sizeof(time_t) > sizeof(long), even when recompile= d=20 from source. I don't think this an issue on sparc64/amd64 -- IIRC long is= =20 already 64 bits on those platforms. Only real solutions I can think of at= =20 the moment are: 1. Go 64-bit for longs on i386. I've seen scattered murmurings that this i= s=20 possible with the current sources and a few folks run systems this way. I'= m=20 pretty sure there's no way to do this without completely breaking the ABI. = =20 Maybe if it coincided with a major libc version bump, and a compat ABI in t= he=20 kernel, with new ELF branding for the 64-bit binaries... Maybe. It could= =20 also have an appreciable performance hit, though those who have been=20 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=20 'correct' approach. I don't know exactly which specs (POSIX? C99?) apply,= =20 but I'm under the impression that no guarantee is made about the size of=20 time_t relative to other basic types. If someone knows for sure, please=20 correct me. This means lots and lots and lots of patches in the ports tree= =2E =20 Even with submitting them back, quite a few would have to be held locally a= s=20 some authors may not care to fix it until Linux does the same thing and=20 forces the issue. As a workaround, maybe there could be a flag in ports fo= r=20 '64-bit time_t clean'. If it's not set, some magic could kick in and build= =20 the port with a 32-bit time_t (activating whatever compat mechanism we have= =20 in place for old binaries). 3. Do nothing on i386. Everybody should have a shiny new =DCberHammer 256-= bit=20 CPU by 2038, right? ;-) Craig
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403142317.09065.craig>