Date: Tue, 16 Mar 2004 13:12:00 -0800 From: Wes Peters <wes@softweyr.com> To: Stephen McKay <smckay@internode.on.net>, current@freebsd.org Cc: Stephen McKay <smckay@internode.on.net> Subject: Re: HEADS UP! MAJOR change to FreeBSD/sparc64 Message-ID: <200403161312.00556.wes@softweyr.com> In-Reply-To: <200403150134.i2F1Y5ew004366@dungeon.home> References: <p060204f5bc750679b827@[128.113.24.47]> <20040315000944.GA93356@xor.obsecurity.org> <200403150134.i2F1Y5ew004366@dungeon.home>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 14 March 2004 05:34 pm, Stephen McKay wrote:
Since Kris and DES have already beaten you severely about the head and
shoulders for your mis-conceptions on how FreeBSD is created, I'll take on
your second point:
> Backward compatibility is very important and can be ignored in only a few
> cases (eg the switch from a.out to elf, or a port to a new architecture).
There is no 'backward compatility' for sparc64. FreeBSD 5.x is still an
active development branch; we have promised we're going to break the ABI at
least once more on every architecture. This is a little bit of pain for a
very few users, and very much part of using a development branch operating
system.
> Also, this is the first I've heard of this since I have no interest in
> sparc. If the intention is to use the sparc conversion is as the
> template for architectures I care about then now the first time I can
> contribute to improving the process.
sparc64 is, afaik, the last 64 bit architecture to change over to 64BTT.
The 32 bit architectures don't matter because the likelihood of them
surviving until when 32BTT becomes a problem is nil. (That's probably true
of the sparc64 architecture too, but keeping sparc64 in line with the rest
of the 64-bitters is a good idea.)
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters wes@softweyr.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403161312.00556.wes>