[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dropping sparc32 for lenny

Jurij Smakov a écrit :
> Hi,
> 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.
> As much as I hate to see Debian lose the support for another 
> subarchitecture, I don't think that anything can be done about it, 
> unless a group of determined and, more importantly, capable people,
> willing to maintain, fix and test it, will emerge. There is also a 
> possibility of separating sparc32 into an unofficial project.
> Any thoughts on the matter will be appreciated. My intention is to 
> come to a rough consensus (if possible), and then present our plan 
> with regards to sparc32 to release managers.

Well that's sad, as the CVS version of QEMU start to emulate sparc32
very well. On the other side I totally understand that we should stop at
some point when the work is more important than the benefit.

I would really prefer to see people working on finishing Sparc V9
emulation in QEMU than fighting with kernel to maintain sparc32 alive.

With my glibc hat on, that would mean one flavour less, which is always
a good thing. That will reduce the size of the build log, and I could
hope it will be small enough to get through the mail servers.

About optimisation, the default optimisation could probably be changed
directly in GCC. Also note that a few binaries (ghc6 for example) are
already optimized for ultrasparc CPUs.

  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Reply to: