
Sparc removal - buster
https://lists.debian.org/debian-devel-announce/2015/07/msg00006.html
======
dmm
I spent a lot of time in the past few months trying to fix enough of the
issues with Debian/SPARC to keep it from having to be removed.

Honestly the port isn't in terrible shape. The specific problems listed as
reasons for removing it are exaggerated. GCC is not dropping 32-bit SPARC code
generation and the kernel works well overall. There were a few issues causing
a lot of breakage, in particular, a register corruption bug in the kernel
memcpy routine and a problem with the gold linker that was corrupting string
literals in certain cases. Those two bugs blocked everything depending on
nettle or qt, 800+ packages.

The real issue is that Debian has high expectations that take maintenance to
fulfill. Particularly with the autobuilders, the machines that produce binary
packages from source. When a build fails there needs to be somebody that fixes
the problem. If an autobuilder crashes it can be restarted but if it's
crashing every day there needs to be someone to track down the problem.

If there is nobody responding to issues it's ok for a while. The people
responsible for packages and the autobuilder infrastructure work around
problems where they can (running old kernels) but eventually it becomes too
much to ask.

So I don't like this decision but it's understandable. The specific problems
are exaggerated but the fundamental one isn't: nobody was doing the work to
keep everything together.

~~~
nothrabannosir
_> The real issue is that Debian has high expectations that take maintenance
to fulfill._

Without meaning to diminish your insightful post and good point: as a Debian
user, I have to say, this does not sound like an issue to me.

~~~
dmm
Sorry if it wasn't clear but I specifically meant the issue for the sparc
port. I was not criticizing Debian in any way.

------
nickpsecurity
What trips me out about this is that SPARC is one of the most open of the
legacy ISA's. It doesn't have so much baggage like Intel. It's RISC. It's
documented well even for firmware writers, unlike Intel's black boxes. The
license to use the name cost $100 rather than ~$1 mil for MIPS or $1-15mil for
ARM. The top, proprietary offerings scream with performance and reliability.
There are also multiple open-source versions that can run on FPGA's and one
which gets fabbed. And, unlike OpenRISC or RISC-V, you get a whole ecosystem
of code and toolsbuilt for the architecture.

Now, I understand people not buying it for desktops when they want to run
browsers, flash, etc. However, it's strange for a crowd (Linux in general)
that's historically about promoting openness and fighting black boxes to have
so little uptake of an ISA like SPARC. Then a popular one drops it due to
nobody maintaining it. A demand side of the equation like that is why few
companies build or open better ISA's. The vendors think most are all talk and
no wallet on the issue if it's about hardware.

~~~
JoshTriplett
Having learned SPARC assembly in the past, it most certainly does have a pile
of backward-compatibility baggage of its own. For instance,
[https://en.wikipedia.org/wiki/Delay_slot](https://en.wikipedia.org/wiki/Delay_slot)

~~~
mzs
It's really not all that bad, there's also the cache coloring and memory
ordering stuff, but it's well documented at least. There is a lot more
historical baroque stuff about x86, like int 80, syscall, or sysenter? For
extra credit how do you find-out and are you sure your approach works on Cyrix
and Via too?

~~~
JoshTriplett
> It's really not all that bad, there's also the cache coloring and memory
> ordering stuff, but it's well documented at least. There is a lot more
> historical baroque stuff about x86, like int 80, syscall, or sysenter?

That's not relevant for current processors; it only matters if you need to
support older processors, and in any case you always use the most capable
interface provided by your processor. The older interface only matters if you
support processors that are well over a decade old. Current processors have to
support old software; current software need not support old processors. So
unless you're hacking on the guts of the Linux syscall layer...

> For extra credit how do you find-out and are you sure your approach works on
> Cyrix and Via too?

Cyrix doesn't exist anymore, and VIA doesn't appear to have any current-
generation hardware. So, unless you used to work on them and you have to avoid
regressions, you can almost certainly safely ignore legacy hardware, just as
you shouldn't optimize code for the Pentium 4 anymore. _Especially_ if you're
writing 64-bit code.

~~~
nickpsecurity
Good points. Important to note that "current generation" hardware means
something different to VIA given they focus on low power and embedded. They do
plenty with 20-30 watts, though:

[http://www.via.com.tw/en/products/processors/quadcore/index....](http://www.via.com.tw/en/products/processors/quadcore/index.jsp)

~~~
JoshTriplett
By "current generation", I was going by the fact that Wikipedia shows no new
models since 2011. If there's something new since then, great.

(And everybody is focusing on low power and embedded these days. Not least of
which because "high performance" and "low power" are really two sides of the
same coin, since if you use less power you generate less heat, and speed
depends heavily on heat dissipation.)

~~~
nickpsecurity
That makes more sense. Remember that it's an embedded board company (mainly),
so they don't iterate as much on SOC's. The last processor, the quad-core
VX11/H, was in 2012 and one of a few on 40nm. Does a lot of stuff for a x86
SOC in 5.8W (max). Their last board design was 2014. So, they're still
chugging along. Most likely two things: slowly moving their I.P. to costly
40nm and developing new ones; moving slower in general because of terrible,
financial situation IIRC. In long run, they'll probably die because they tried
to compete in x86 and even mighty AMD with their volume & engineers haven't
pulled that off.

Far as low power, not everybody is focusing on _x86-compatible_ , low-power
chips these days. I only know three vendors: Intel, AMD, and VIA. So, it's
that stuff that's relevant to a VIA comparison if we're talking x86 and legacy
software/OS needing it. Students in labs throw together low-power, ARM/MIPS
clones as a side effect of their simplicity and process node. x86 is so
complicated that it took smart, HW engineers to do that with only a few
companies trying and most gone. It's again why I'm anti-x86: entirely too
complicated compared to multi-core RISC with hard-wired accelerators. See
Cavium's Octeon III for an awesome example of that.

[http://www.cavium.com/OCTEON-III_CN7XXX.html](http://www.cavium.com/OCTEON-
III_CN7XXX.html)

------
rurban
Very likely wrong alignment. This causes hard SIGBUS faults, and SPARC64 is
one of the good platforms to catch such misaligned pointers. You cannot repro
it in qemu on Intel.

But I don't know what ElfW(Rel) expands to. Maybe only a 4byte word, not 8.
The backtrace doesn't display the register content (THANKS gdb maintainers),
and the op didn't provide the registers neither.

    
    
      0xfffff8010000cda4 in elf_dynamic_do_Rela (skip_ifunc=<optimized out>, lazy=0, nrelative=<optimized out>, relsize=<optimized out>, reladdr=<optimized out>

[https://lists.debian.org/debian-
sparc/2015/07/msg00013.html](https://lists.debian.org/debian-
sparc/2015/07/msg00013.html)

------
w8rbt
OpenBSD still supports it. It's very stable too.

~~~
dmm
It supports cool stuff like acting as an ldom host too.

[http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-
current/man8/...](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-
current/man8/sparc64/ldomd.8?query=ldomd)

~~~
stsp
Better documentation link which shows how to set it all up:
[http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-
current/man8/...](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-
current/man8/sparc64/ldomctl.8)

------
yrmt
NetBSD welcomes all SPARC owners

------
justaaron
what about openSPARC, one of the only truly open cpu designs one can load into
an fpga

~~~
nickpsecurity
And the Gaisler Aeroflex cores that are both open-source and fabbed onto
boards they sell. People who want open hardware can get a bit closer with a
4-core SPARC board. :)

------
justincormack
The linked message says it could come back as sparc64 - the Debian port was a
32 bit userspace, optionally 64 but kernel, while on new sparc machines you
probably would want to use sparc64 userspace. For embedded/fpga sparc it is
less clear. Anecdotally though I think there are more NetBSD/OpenBSD users on
sparc than Linux.

~~~
dmm
This port only ran on 64-bit machines. Support for 32-bit sparc cpus was
dropped years ago.

------
yellowapple
Well darn; I guess now I can't run Debian on my Sun Fire T2000.

Not that I particularly care, since I've found OpenBSD to be _much_ better on
non-x86 (particularly SPARC and PowerPC) hardware than pretty much every
GNU/Linux distro I've tried (Debian included), but it's still unfortunate;
diversity is nice to have in a platform, even if I'm pretty happy in BSD-land.

Oh well. Perhaps if us SPARC users are lucky, more illumos distros will start
supporting SPARC. Tribblix looks interesting; if I can ever get my Blade 1500
running again, I'll have to try that one out on it.

------
omginternets
><liw> HE, we had sex in Debian for many years, yes, before I put a stop to it

Could someone explain wtf this means?

~~~
baghira
Probably related to the "Simple editor for X".

~~~
omginternets
Ah, that makes more sense than OSS devs getting laid ;)

~~~
amyjess
Hey, Ian Murdock _did_ name Debian after him and his girlfriend...

~~~
JupiterMoon
They _did_ break up though.

~~~
nickpsecurity
This whole sub-thread: DAAAAAAMN! Haha. Let it be a warning to OSS developers
thinking of mixing business and pleasure. Except for the pleasure of coding.
:)

------
4ad
Note -- this is 32-bit SPARC, not SPARC64. I am surprised to see that Debian
does not have an official SPARC64 port (it has an unofficial one).

~~~
dmm
Support for 32-bit sparc was dropped years ago. This was the port for 64-bit
machines even though it used a 32-bit userland.

------
decafbad
What's byhand?

~~~
detaro
BYHAND are uploads that are not normal packages and need manual intervention
to be processed.

------
DonHopkins
CRAPS!

