Re: Dropping sparc32 for lenny
Hi,
Jurij Smakov <jurij@wooyd.org> writes:
> Now that we have released, we need to set our goals for the future. As
> you probably guessed from the subject, I am strongly in favor of
> dropping sparc32 support for lenny. There are multiple reasons for it,
> including
>
> * Nearly complete lack of upstream support. David Miller, current
> upstream maintainer of sparc64 has expressed his thoughts on the
> topic in [0], triggering the discussion about dropping sparc32
> support in Aurora Linux. [1]
> * Several serious problems, like lack of SMP support and driver
> failures (CD-ROMs do not work for some reason).
> * Shrinking userbase, flaky hardware.
> * Possibility to build the archive with optimization for UltraSparc
> processors, leading in some cases to significant performance
> improvements.
This is sad, but not much surprising.
As a pure user, I regret that the Linux kernel has regressed so much
between 2.4 and 2.6. 2.6 is apparently catching up now, but it's been
such a long time since 2.6.0. To some extents, it looks like kernel
developers had made that decision a long time ago---beware, I do not
blame anyone for it!
As for the current state of affairs kernel-wise, I think Joël Bertrand
reported that 2.6 is in a good shape compared to the latest 2.4 kernels,
including SMP. HyperSPARC are still mostly unsupported, although I
believe this is mostly due to a lack of understanding of what's
"special" about them, since they mustn't be so different from "regular"
SPARCs (or are they?)---agreed, it takes more than belief to actually
fix it. ;-)
On the bright side of things, David Miller rewrote the OBP code back in
June [0]; he has also just rewritten the ESP driver that has been
causing so many troubles [1], which is primarily beneficial to sparc32
AFAIK. Completely dropping upstream support seems rather unlikely for
the time being as (at least) the makers of the LEON processor have
interest in it [2]. Also, AFAIK, GCC, Binutils and Glibc are not
decaying.
Admittedly, these are not strong arguments, all the more that I'm not
stepping up to fix the remaining bits. Nevertheless, if there are no
compelling reasons to drop sparc32 now (e.g., if the optimizations that
would be gained for sparc64 are not worthwhile, which I suspect), this
might suffice to at least postpone the decision making.
On a more philosophical or ethical note, it would be disappointing to
drop architectures that are no longer considered cutting-edge by us,
people from wealthy regions. Proprietary software vendors certainly
won't care. Then Free Software people probably should care.
In any case, thanks to all the people who've been working on the sparc32
Debian port and kernel.
Ludovic.
[0] http://article.gmane.org/gmane.linux.ports.sparc/6322
[1] http://article.gmane.org/gmane.linux.ports.sparc/7396
[2] http://article.gmane.org/gmane.linux.ports.sparc/7339
Reply to: