Re: Concerns about AMD64 port
Stephen Frost <sfrost@snowman.net> writes:
> * Goswin von Brederlow (brederlo@informatik.uni-tuebingen.de) wrote:
> > John Goerzen <jgoerzen@complete.org> writes:
> > > 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/.
>
> There's some confusion here. When *you* say 64bit userspace you're
> talking really about 64bit userspace with the ability to install 32bit
> apps. What John was talking about was 64bit *native*/only. The webpage
> isn't clear on this either, which it should be, really.
I'm talking about one that follows the official guidelines and is
compatible with other linux amd64 distributions. That means a cripled
mixed system, i.e. mixed system with all the 32bit stuff missing.
> > Developing a standalone 64 bit system thats incompatible to the mixed
> > system is work wasted.
>
> It's not wasted because it would get used a fair bit before the mixed
> system is available. True, once the mixed system is complete it
> wouldn't be needed anymore, but that doesn't make the time spent on it
> wasted just because it'll be depreceated some time in the future.
> That's a bit like saying that building a car now is work wasted because
> in 2 years a new model will be out.
You can use the existing i386 or multiarch setup just fine right
now. You are proposing to design a unicycle on the way from the
bicylce to a tricycle.
Its also a hell of a lot easier to bootstrap the 64 bit packages with
the existing 32 bit packages supplying build-depends. A lot of
Depends/Build-Depends cycles can be broken that way.
> > > 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.
>
> We have support for >4GB ram in the 32bit kernel and if you're talking
> about a 32bit system you're not going to be able to use more than that
> per task, obviously. Such a 'slightly unpure' 32bit only system isn't a
> 32bit only system anymore, it's a 32/64 mixed system.
I doubt the >4GB support in i386 kernels is compatible to the way
amd64 handles ram.
> > > 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.
>
> Sure, you're throw it away, but it'd be useful sometime this year, which
> the mixed stuff doesn't seem likely to be, imv. What really annoys me
> is that we could have had a 64bit only system back in July or some such
> but instead people decided to jump right to the 32/64bit stuff, which is
> still being worked on and has yet to even be formed and agreed to about
> *how* it's going to be done.
The only thing I see as not being agreed on is the packaging
stuff. Everything else has been set for some time. Whats left to
decide is the extend and form of multiarch support for all archs. If
you don't want multiarch on amd64 you are welcome to start a 64bit
only repository. Once you get base+build-essential setup I can run a
buildd for it within a days notice. But you would realy duplicate a
lot of work that multiarch people are already working on.
> > The problem, as said above, is getting each file in the right
> > place. Otherwise upgrading to a mixed system will be hell or
> > impossible.
>
> It's only a problem of putting it in the 'right' place if you want the
> 'right' place to be /lib64 or /usr/lib64 instead of just building a
> pure-64bit port.
Thats whats needed for compatibility with existing guidelines and
distributions.
> > 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.
>
> Right, yet all of those other archs already have a real port and people
> can use them today. amd64 doesn't have that except in the crippled i386
> arch.
Which isn't realy crippled. Apart from speed, which is hardly a
pressing factor normaly, the only advantage of amd64 is the bigger
address space.
> > 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.
>
> It's not wasted because it'd be done quickly and used by all of the
> people who are bitching that we don't have an amd64 port *today*. I
> expect we're going to continue to see these mails and complaints over
> the next year before multiarch support works and likely for every 1 mail
> we see there's 20-50 other people who just read the webpage and said
> "well, forget that."
>
> Stephen
Good riddance. (sorry)
Anyone who thought amd64 would get released with sarge is just plain
nuts. A newly started port can never hold up to the stability and bug
freenes of the old ones. Two month after a sarge amd64 release it
would probably be as obsolete as woody is now.
For anyone willing to run unstable Debian has a multiarch port on
alioth *today*. Whats needed for it to mature (and to catch up to
sarge) is people willing and able to invest time into fixing
libc6. Thats the most pressing issue I'm aware of.
MfG
Goswin
Reply to: