Re: Dropping sparc32 for lenny
Ludovic Courtès a écrit :
Hi,
Hello,
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. ;-)
For me, there are some reasons to continue sparc32 support :
1/ today, there is no real alternative (Solaris 7 is the last SunOS able
to support all sun4m architectures. Solaris 9 only supports sun4m with
two processors. NetBSD 3.x is a little broken broken [SMP support] and
NetBSD 4.0 is totally broken : even the fb does not work. OpenBSD does
not support SMP stations...).
2/ sparc32 is used (not regular sparc hardware, but leon processor that
is a sparc v8 proc).
3/ the only difference between sparc32 and sparc64 userland is the
kernel. Today, userland of both arch is the same, and I'm not sure we
obtain a very great gain when we shall turn on all sparc V8+
optimizations. For example : I have rebuilt mysql-server (5.0.38) on a
U2 (2 GB) with _all_ Ultrasparc optimizations and I haven't seen any
difference between the V8-package and this V8+-package.
4/ The last 2.4 kernel that is _usable_ is the 2.4.21 if I remember. All
releases after this kernel are not usable for production workstations
(on sparc32 [that randomly crash with 'watchdog error'] _and_ sparc64
[that randomly freeze without any message]). I haven't found any stable
kernel between 2.4.21 and 2.6.21-rc7. Thanks to Davem to the IOMMU/Sbus
patch.
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.
And Debian/sparc32 is the last distribution that supports sparc32.
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.
Regards,
JKB
Reply to: