Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 09:08:15PM +0100, Goswin von Brederlow wrote:
> Sven Luther <sven.luther@wanadoo.fr> writes:
>
> > On Mon, Mar 14, 2005 at 10:16:20AM +0000, Martin Michlmayr wrote:
> >> * Aurélien Jarno <aurelien@aurel32.net> [2005-03-14 10:56]:
> >> > Would it be possible to have a list of such proposed architectures?
> >>
> >> amd64, s390z, powerpc64, netbsd-i386 and other variants, sh3/sh4, m32r
> >
> > ppc64 is not currently a candidate for a separate arch, the path to go is a
> > biarch solution, much like the current amd64 solution in sarge, as word from
> > the main ppc64 developers is that a pure64 solution will be a measurable
> > performance hit on power (unlike amd64, which is saddled with a weaker
> > instruction set to start with).
> >
> > One could add per-subarch optimized builds and mirrors too though.
> >
> > Friendly,
> >
> > Sven Luther
>
> The way to go is to have a seperate architecture but with a very
> limited set of packages. This allows packages to keep the same name
> instead of prefixing with the bit with (libc6 instead of lib64c6,
> zlib instead of lib64z). This also hides the 64bit packages for users
> of ppc32 as their setup would not include the ppc64 architecture.
Well, the main problem about this is that consensus from the IBM linux ppc64
guys is that doing pure-64bit on ppc64 is a performance hit, and thus not
worth it. Instead it should be privilegied to run userland in 32bit over a
64bit kernel, and only do ppc64 builds of the apps that will benefit from them
(mostly databases and other much memory stuff). Of the other ppc64 supported
distribs, only gentoo has gone the pure64bit way (well because being a source
distrib, they can afford it, but they take the performance hit for it), and
suze/redhat/whoever has gone the biarch way, mostly for the above resons.
> Multiarch porting needed for i386/amd64 needs every package compiled
> for both. People do want pure 64bit amd64 installs. 3rd party
Sure, because going from 6 registers to 14 is a huge benefit.
> software for i386/amd64 needs a lot of libs, much more than ppc64
> would need, and doing those the current biarch way is insane compared
> to multiarch. It would also duplicate all those packages as 32bit
> amd64 and 64bit i386 package.
>
> And once multiarch is in the source ppc64 just has to start the
> buildd. Doing biarch for ppc on top of that would be stupid.
Well, when multiarch would be ready, then it can maybe moved that way, i don't
know, i think how the things are organized is orthogonal to how many packages
and which gets rebuilt. We first need a biarch toolchain so i can build ppc64
kernels.
> So my suggestion for ppc64 (and all other !amd64 multiarchs) is to
> either add lots of packages to p-a-s (more sensible would be a white
> list), add lots of packages to NFU in wanna-build or provide a large
> no-auto list to the buildds to keep out unneccesary packages and treat
> it just like any other arch otherwise.
Let's first try for a toolchain and proper ppc64 kernels and psutils binary,
we can build from there as needed.
Friendly,
Sven Luther
Reply to: