* 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. > 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. > > 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. > > 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 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. > 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. > 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
Attachment:
signature.asc
Description: Digital signature