Sparc64 doesn't care about you, and you shouldn't care about Sparc64

[Peter Jeremy]

[Adding sparc64]

On 2015-Nov-04 11:12:19 -0800, Sean Bruno <sbruno at freebsd.org> wrote:
>So here's the thing, Sparc64 is *just* barely alive in FreeBSD.
>
>There is exactly 1 Sparc64 machine as a ref box being hosted at Yahoo
>for the project.  No new hardware is on the horizon.  None of the newer
>Sparc64 processors have been tested to work on FreeBSD and nobody is
>clamoring to get them working.
>
>We're moving into a post-gcc base system now, and sparc64 is the obvious
>"odd arch" here.  There's activity to get MIPS moved to clang and active
>work to get powerpc moved fully to clang.  Leaving Sparc64 in base,
>requires someone to either make clang DTRT or keep gcc 4.2.1-ish alive.

I don't think the latter is an option.  Doing so means that the entire
machine-independent codebase needs to be compilable with gcc 4.2.1,
blocking the use of any new feature.  IMHO, this should be around the
other way: FreeBSD 11.x will require all supported architectures to be
buildable with clang.

http://llvm.org/releases/3.5.0/docs/ReleaseNotes.html states that clang
can self-host on FreeBSD/Sparc64 so this doesn't seem an unreasonable
requirement.

>I have asked around for help getting the Sparc64 qemu-bsd-user binary
>working so I could at a minimum build packages, and I have gotten no
>feedback from folks.  So the only option here is to resurrect sparc64
>machines somewhere and start up builds on real hardware.
>
>Let's just call it what it is, a dead end of the technology tree.
>I move that we do NOT produce 11.0 versions for Sparc64 and it should be
>dropped from the tree.

I agree.  Even if the compiler issues are resolved, there doesn't
appear to be the critical mass within the Project to keep the
architecture alive.

I also feel that no 11.0 FreeBSD/sparc64 makes much more sense than
axing support just after 11.0 - if we release 11.0 on sparc64, we are
pretty much committed to supporting sparc64 for the life of the 11.x
branch and supporting an orphaned architechure for that long is going
to be extremely painful.  OTOH, I feel it's reasonable for the code to
not be axed until after 11.0 in case there's a sufficient groundswell
of support to reverse the deprecation decision.

Taking the FreeBSD/alpha deprecation as a precedent, deprecation was
officially announced in May 2006:
https://docs.freebsd.org/cgi/getmsg.cgi?fetch=14637+0+archive/2006/freebsd-alpha/20060514.freebsd-alpha
with the website updated a couple of months later:
https://svnweb.freebsd.org/doc/head/en_US.ISO8859-1/htdocs/platforms/alpha.xml?revision=28282
and the family tree shows:
FreeBSD 6.0             2005-11-01 [FBD]
FreeBSD 6.1             2006-05-08 [FBD]
FreeBSD 5.5             2006-05-25 [FBD]
FreeBSD 6.2             2007-01-15 [FBD]
FreeBSD 6.3             2008-01-18 [FBD]
FreeBSD 7.0             2008-02-27 [FBD]

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20151105/d3c36207/attachment.bin>