Sparc64 support

[Jordan Hubbard]

> On Aug 9, 2015, at 11:03 PM, Adrian Chadd <adrian.chadd at gmail.com> wrote:
> 
> poke dim and the other compiler-y people. They have a plan, and it's
> about time we started the deorbit. :)

Well seriously though, let’s also take this opportunity to clean things up with the build process and maybe also some of the release bits too, since they’re fairly intrinsically tied together.

I tried doing a “make release” in /usr/src today, harkening back to the days when I was Release Engineer for FreeBSD and that single command was all one needed to get a .iso image and some boot floppy / QIC tape suitable media (!) for the i386.  Obviously there are more release products now, from single disc ISOs to DVDs to USB boot device installers, and I quickly saw that all of these various targets had moved into /usr/src/release (OK, that seems reasonable) but even then, and after reading /usr/src/release/Makefile, I could not get “make cdrom” to work.  Looking at https://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/release-build.html references a script that doesn’t even exist anymore, so the docs are clearly out of date.

My point, and I do have one, is that while we’re cleaning things up, and I think we should, there should be some clear goals to what we’re doing:

1. The “buildworld, buildkernel and release” targets should DTRT with a known and documented set of target switches like TARGET_ARCH and whatever else is deemed “minimally necessary” to cross-build, or self-host for that matter, on any given platform.  Where self-hosting is the scenario, the defaults should also be set reasonably enough to make those build targets Just Work with a minimum [absence] of superfluous decorative flags or variables.

In short, the Principle Of Least Astonishment is an excellent guiding principle to follow and the minute someone says “well, it’s totally obvious how to build for the beagleboner 9000, you just go to http://www.4chan.org/os-stuff/giggle/he-said-boner/davesdocs/howtomakefreebsd.html and follow the instructions there after also customizing the first 30 lines of the whiffle.sh script”, we should be allowed to kill them and eat their liver with some fava beans and a nice chianti.  Then we should automate it and document it on our own web site.

2. We need to define what the targeted architectures are for “round one” of this because reading https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.html is only partially enlightening.  According to that, only i386 and amd64 are tier 1 and tier 2 are ARM, pc98 (really??), powerpc and sparc64.  In Tier 3, in a lonely classification all by itself, is mips.  Even if we adopt all of them, which of those require an external toolchain and which will build with the current clang?  If you read papers like http://llvm.org/devmtg/2014-04/PDFs/LightningTalks/2014-3-31_ClangTargetSupport_LighteningTalk.pdf you could easily develop the impression that even its own developers aren’t so sure, but I’m guessing we have a bit better of an idea than that, no?

3. We need to collect all of the cross-building voodoo in one place and then set about encoding it into the Makefiles such that even a reasonably intelligent golden retriever can build one or all of the supported target architectures.  For extra credit, they should also be able to pop out an installation image for it since the Release Engineer often has better things to do than build custom images for folks, but that’s also the only way to really TEST anything so “self service” should definitely be possible and even sort of fun.

4. We need to de-orbit gcc as previously discussed since nobody can claim that this is regressive motion if there is a plan for the 88000 and i860 ports and they even work better than they did before.

I have a lab (several actually).  I have engineers.  How can we help.

- Jordan