From owner-freebsd-current@FreeBSD.ORG Sun Mar 14 21:17:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1ED8116A4CE for ; Sun, 14 Mar 2004 21:17:51 -0800 (PST) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0044C43D31 for ; Sun, 14 Mar 2004 21:17:51 -0800 (PST) (envelope-from craig@xfoil.gank.org) Received: from [192.168.69.84] (arbiter.gank.org [64.81.113.221]) by ion.gank.org (mail) with ESMTP id 0DBB62A931; Sun, 14 Mar 2004 23:17:15 -0600 (CST) From: Craig Boston To: freebsd-current@freebsd.org Date: Sun, 14 Mar 2004 23:17:09 -0600 User-Agent: KMail/1.6.1 References: <200403140716.i2E7GDKa007204@dungeon.home> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200403142317.09065.craig@xfoil.gank.org> cc: Garance A Drosihn cc: Stephen McKay Subject: Re: HEADS UP! MAJOR change to FreeBSD/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2004 05:17:51 -0000 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