Re: Sparc release requalification
On 18.08.2009 22:43, Jurij Smakov wrote:
Hello,
I would like to point out that sparc release requalification is currently
placing it in "at risk" position for squeeze release. The most serious
problems with the port are lack of developer involvement (there is currently
one active porter/developer known to the release team, Bernd Zeimetz) and
the fact that current mixed 64-bit kernel with 32-bit userspace setup is
not supported upstream (CC'ing doko for comment).
The current configuration for a biarch toolchain defaulting to 32-bit isn't that
well supported. The 32-bit compiler defaults to v8 hardware which isn't
available anymore. The biarch setup tightly couples v9 and newer processor
support to 64-bit, so switching to a 64-bit userland would offer better use of
current hardware besides targeting a comparable setup as other distributions.
Newer projects like llvm don't target 32-bit sparc anymore, while they do for
64-bit.
I did speak with Martin Zobel at Debconf on how to get there, having two proposals:
- define a new sparc64 port, and bootstrap this one using the 32bit port.
- have an inplace-transition building required library packages for an
upgrade as biarch packages and continue to use the current sparc name.
For both variants the toolchain is almost in place. glibc and binutils don't
need modifications, gcc needs some libraries be built as biarch on sparc. zlib
is already built as biarch on sparc. gmp and mpfr are already built as biarch on
other archs, ppl and cloog would be good to have, but we could start without the
graphite optimizations as well.
I can prepare the changes for gcc, but will not help with any other transition work.
[CCing debian-s390, because there are plans for a switch to s390x as well]
Matthias
Reply to: