Sparc64 support

[Peter Jeremy]

On Aug 9, 2015 2:59 PM, "K. Macy" <kmacy at freebsd.org> wrote:
> Please bear in mind that the number of developer man hours of that caliber
> is extremely limited. Working on SPARC only makes sense for a developer who
> wants to have a free hand in making changes to the MD code that he simply
> can't on x86 or simply really enjoys working on it as a niche platform. The
> return on investment of sustaining a marginal architecture represented only
> by outdated hardware is really vanishingly small vis a vis supporting
> recent laptops, better support for newer cloud platforms, and countless
> other areas where FreeBSD is struggling to keep up with the Joneses.
>
> I'm not saying that people who currently work on SPARC should stop doing
> so. I'm simply pointing out that as avenues for facilitating wider use of
> FreeBSD go, it's a bit lacklustre.

On 2015-Aug-09 15:08:39 -0500, Bill Sorenson <instructionset at gmail.com> wrote:
>I don't entirely disagree. As long as sparc64 works I'm glad it stays in. I
>don't personally see sun4v support being much of a priority, unless Oracle
>pulls a rabbit out of their hat and makes sparc competitive again.

IMHO, FreeBSD/sparc64 is currently in a very similar situation to what
FreeBSD/alpha was in 2007-8: The architecture has been taken over by a
vendor who has no interest in its future and, as a result, the number of
FreeBSD developers who are both interested in supporting it and have the
technical acumen to do so is diminishing.  SPARC has the advantage that it
was much more popular than AXP so there's a lot more surplus hardware
floating around (though the lack of sun4v support means that not all of it
can be used with FreeBSD).

At this stage, it's not clear that SPARC has the critical mass of interest
needed to ensure its ongoing viability.  Continuing to support an
architecture incurs a non-zero cost to the Project as a whole so continuing
to suppport SPARC needs to demonstrate a benefit to justify that cost.

The costs include:
- Whilst sparc64 remains tied to gcc4.2.1, FreeBSD as a whole can't take
  advantage of newer C constructs.
- Developer resources need to be spent ensuring that changes don't break
  sparc64 (and, potentially, worthwhile features won't be implemented in
  FreeBSD as a whole because supporting sparc64 is too hard).

The benefits include:
- Having a native big-endian architecture to catch endian-dependent bugs.
- Advocacy - this thread demonstrates that people have built a business
  around FreeBSD/sparc64 and, in the absence of sparc64, they would move
  to a different OS.

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