Re: Concerns about AMD64 port
John Goerzen <jgoerzen@complete.org> writes:
> On Thu, Feb 05, 2004 at 03:55:47PM +0100, Goswin von Brederlow wrote:
> > John Goerzen <jgoerzen@complete.org> writes:
> > > The only reason I can see for even bothering to support 32-bit
> > > applications at all is for binary-only proprietary software. And that
> > > is not such a concern; it takes all of about 10 minutes to set up a
> > > 32-bit chroot with debootstrap to run those things in.
> >
> > That implies you have a kernel with 32bit emulation compiled in. So
> > you are running a biarch system and not pure 64bit.
>
> True, but everything else the ports page mentions will require it, since
> it's basically required for everything out there for Debian right now.
>
> > > So it seems to me that the great benefit to many people of having a
> > > native 64-bit userland has been sacrificed for the questionable benefit
> > > of being able to run proprietary software without making a chroot. I am
> > > still a little shocked about that.
> >
> > Our big goal is to support A) pure 32bit i386, B) mixed 32/64 bit
> > i386/amd64 and C) pure 64bit amd64 userspace.
>
> If a pure 64bit userspace is the goal, why does the AMD64 ports page say
> such a thing is "academical and of little use"?
Because the 64bit only userspace will be the mixed userspace with the
32 bit stuff missing. It will still be the 64bit part of the mixed
systems. That means e.g. that libs are in /lib64/ and /usr/lib64/.
Developing a standalone 64 bit system thats incompatible to the mixed
system is work wasted.
Any other reasons are beyond me.
> Can't A be accomplished simply by building a standard i386 kernel and
> using a standard i386 distro? IOW, don't we already have that?
yes. But a 64bit kernel for >4GB ram support (alltogether, not per
task) would still be nice. A slightly unpure 32bit only system is
probably best.
> B seems like the toughest thing to accomplish. Wouldn't it make more
> sense to get C done first, and then once the 64-bit userspace is
> functional, add on the 32-bit emulation?
No, you would have to throw it away to change to a mixed mode. The
problem is getting the 64bit stuff out of the way of the 32 bit stuff
and not compiling for 64 bit.
> > For some crucial things likes libc6 it doesn't look like we can get
> > rid of the 32bit flavour though. But apart from a bit of bloat here
>
> Are you saying that libc6 cannot build as a 64-bit package?
No, it just looks to complex to build a standalone 64 and 32 bit
package that also work together. Currently the 64bit package depends
on the 32 bit package. For something as essential as libc6 thats fine
for now.
> > and there nothing stands in the way of a pure 64 bit amd64
> > system (Except your time and willingness to port stuff).
>
> Like I mentioned, there is not much manual effort here; most software is
> already 64-bit clean.
The problem, as said above, is getting each file in the right
place. Otherwise upgrading to a mixed system will be hell or
impossible.
> > > Can someone explain what is going on here?
> >
> > Its a transition. Its all a mess untill stuff is cleaned up, things
> > have been tried and decided upon.
>
> I'm a little unclear on what we're transitioning from and to. It's a
> new arch, never before supported in Debian; where is the transition?
/lib/ -> lib64/,... , one arch -> multiarch
> It seems to me that the fact that this arch has a particular feature
> (the ability to run 32-bit apps) is causing us to ignore the primary
> point of the arch (the ability to run 64-bit apps) because of this one
> incidental feature. Is not AMD64 perfectly usable with a pure 64-bit
> userland? Could not people that want a 32-bit userland install an
> existing i386 Debian distro?
>
> -- John
Your missing that multiarch support is a problem for mips64, mipsel64,
powerpc64, s390x, sparc64 and amd64. Only amd64 is in the position
that 64bit apps are nearly allways prefered and wouldn't hurt
performance otherwise.
Solving the problem just for amd64 by ignoring the 32bit support would
be a hell of a lot easier but work wasted when multiarch replaces it.
MfG
Goswin
Reply to: