The recent discussion about having a "real" x86 arch team and combining the x86 and amd64 keywords was both interesting and provocative. Of course, this is the sort of thing that the GLEP system was meant for. Now that we have a new council that (I hope) will be active in approving or rejecting GLEPs, perhaps someone should be writing a GLEP about combining x86 and amd64?
>> Now that we have a new council that (I hope) will be active in approving >> or rejecting GLEPs, perhaps someone should be writing a GLEP about >> combining x86 and amd64?
> I'm not sure if it's really worth writing another GLEP for an april's > fool...
Grant Goodyear wrote: > The recent discussion about having a "real" x86 arch team and combining > the x86 and amd64 keywords was both interesting and provocative. Of > course, this is the sort of thing that the GLEP system was meant for. > Now that we have a new council that (I hope) will be active in approving > or rejecting GLEPs, perhaps someone should be writing a GLEP about > combining x86 and amd64?
On Thursday 01 September 2005 19:10, Grant Goodyear wrote:
> Now that we have a new council that (I hope) will be active in approving > or rejecting GLEPs, perhaps someone should be writing a GLEP about > combining x86 and amd64?
I hope this not. As (iirc) I already said, it's impossible to combine x86 with anything else that's not 100% source and binary compatible with itself... The reason is actually simple: x86 is, or at least was, the reference architecture for almost all programmers. There are too many packages that works *just* on x86, both at source and binary level. Using a single keyword would make us unable to mark for example helixplayer (source) x86 and -amd64 at the same time (as it's now). While it can be simple to do for sparc or ppc that has relatively less users, and with no need for binary compatibility for -bin packages, it's probably going to be a *great* pain for both users AND developers of x86 and amd64 platforms (most probably for the latter, as x86 has basically no needs for multilib and so on).
Grant Goodyear wrote: > Now that we have a new council that (I hope) will be active in approving > or rejecting GLEPs, perhaps someone should be writing a GLEP about > combining x86 and amd64?
I'm not sure if it's really worth writing another GLEP for an april's fool...
-- Simon Stelling Gentoo/AMD64 Operational Co-Lead bl...@gentoo.org -- gentoo-...@gentoo.org mailing list
On Thursday 01 September 2005 19:39, Stephen P. Becker wrote:
> Witih amd64 becoming so widespread, this will change.
You think it's a thing that changes in 2 days?
> Doesn't the amd64 team have a set of 32-bit compat libs just to run > binary packages? When running 32-bit code, isn't amd64 basically just a > glorified athlon-xp?
Kernel-level code doesn't work. Some 32-bit binaries fails to work, and the emul-libs are NOT a way to say "it's 32-bit"... There are TOO many differences...
About p.mask.. no I don't like that solution, p.mask is good for a platform profile (for example bsd's, darwin's or linux's), but not to arch level, we have -* keywords for that, haven't we?
On Thursday 01 September 2005 01:39 pm, Stephen P. Becker wrote:
> > There are too many packages that works *just* on x86, both at source and > > binary level.
> Doesn't the amd64 team have a set of 32-bit compat libs just to run > binary packages? When running 32-bit code, isn't amd64 basically just a > glorified athlon-xp?
yes, assuming user wants that ... not everyone wants multilib crap on their machine ... i know i'd prefer to have a 100% non-multilib system if i could get away with it -mike -- gentoo-...@gentoo.org mailing list
| I hope this not. As (iirc) I already said, it's impossible to combine | x86 with anything else that's not 100% source and binary compatible | with itself...
Untrue.
| Using a single keyword would make us unable to mark for example | helixplayer (source) x86 and -amd64 at the same time (as it's now).
Untrue.
| While it can be simple to do for sparc or ppc that has relatively | less users, and with no need for binary compatibility for -bin | packages, it's probably going to be a *great* pain for both users AND | developers of x86 and amd64 platforms (most probably for the latter, | as x86 has basically no needs for multilib and so on).
Untrue.
-- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail : ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm
> I hope this not. As (iirc) I already said, it's impossible to combine x86 with > anything else that's not 100% source and binary compatible with itself... > The reason is actually simple: x86 is, or at least was, the reference > architecture for almost all programmers.
Witih amd64 becoming so widespread, this will change.
> There are too many packages that works *just* on x86, both at source and > binary level.
Doesn't the amd64 team have a set of 32-bit compat libs just to run binary packages? When running 32-bit code, isn't amd64 basically just a glorified athlon-xp?
Stephen P. Becker wrote: >> Using a single keyword would make us unable to mark for example >> helixplayer (source) x86 and -amd64 at the same time (as it's now).
> So package.mask it in the (now hypothetical) amd64 sub-profile, and it > is fixed.
That's exactly why i don't like the idea of merging keywords: You loose the ~arch state. Quite a big share of packages work without a single issue on x86, but they're still experimental on amd64 (although they generally work). And x86 devs wont wait on us just because we say 'nooo, not stable enough' nor will they fix our bugs, as most of them aren't reproducible on x86.
Also, you can't compare sparc32/sparc64 to x86/amd64: sparc64 is just a 64bit kernel with a 32bit userland. For users who want that, there is already a keyword: x86.
-- Simon Stelling Gentoo/AMD64 Operational Co-Lead bl...@gentoo.org -- gentoo-...@gentoo.org mailing list
Simon Stelling <bl...@gentoo.org> wrote: > Also, you can't compare sparc32/sparc64 to x86/amd64: sparc64 is just > a 64bit kernel with a 32bit userland.
However, that can't be said of mips, where one keyword covers 32- and 64-bit kernels with three different userland ABIs, each with its own set of new and interesting bugs. -- gentoo-...@gentoo.org mailing list
What structure are you thinking about for the 'real' x86 arch?
would there be a meta-x86 and then two sub-archs? ie. --real_x86--+--x86--~x86 +--amd64--~amd64
where {real_x86}={x86}INTERSECT{amd64}.. ?
Lares
On Thu, 2005-09-01 at 12:10 -0500, Grant Goodyear wrote: > The recent discussion about having a "real" x86 arch team and combining > the x86 and amd64 keywords was both interesting and provocative. Of > course, this is the sort of thing that the GLEP system was meant for. > Now that we have a new council that (I hope) will be active in approving > or rejecting GLEPs, perhaps someone should be writing a GLEP about > combining x86 and amd64?
On Thursday 01 September 2005 01:39 pm, Stephen P. Becker wrote:
> > I hope this not. As (iirc) I already said, it's impossible to combine x86 > > with anything else that's not 100% source and binary compatible with > > itself... The reason is actually simple: x86 is, or at least was, the > > reference architecture for almost all programmers.
> Witih amd64 becoming so widespread, this will change.
will != now
maybe down the road i'd be for this, but right now i think it's just a waste of time ... too many packages suck at life ... just yesterday i fixed a new release (made in the last month) of a package which loved to cast pointers to 'int' and then try to use the result -mike -- gentoo-...@gentoo.org mailing list
> yes, assuming user wants that ... not everyone wants multilib crap on their > machine ... i know i'd prefer to have a 100% non-multilib system if i could > get away with it
Then that is fine, as you would never be affected by binary packages, and they would be profile masked for you.
>>> Using a single keyword would make us unable to mark for example >>> helixplayer (source) x86 and -amd64 at the same time (as it's now).
>> So package.mask it in the (now hypothetical) amd64 sub-profile, and it >> is fixed.
> That's exactly why i don't like the idea of merging keywords: You loose > the ~arch state.
We weren't talking about ~arch, we were talking about -arch.
> Also, you can't compare sparc32/sparc64 to x86/amd64: sparc64 is just a > 64bit kernel with a 32bit userland. For users who want that, there is > already a keyword: x86.
Wrong again. On mips, we have 64-bit kernels with *three* different possible userlands, n64, n32, and o32, and we do just fine (although as of right now, we haven't bothered to make any n64 stages since they would run slower than n32 and o32 on all of our supported hardware).
Stephen P. Becker wrote: >> That's exactly why i don't like the idea of merging keywords: You >> loose the ~arch state.
> We weren't talking about ~arch, we were talking about -arch.
I'm talking about ~arch. And it's a fact that ~arch would get lost, so the scenario i mentioned isn't covered.
>> Also, you can't compare sparc32/sparc64 to x86/amd64: sparc64 is just >> a 64bit kernel with a 32bit userland. For users who want that, there >> is already a keyword: x86.
> Wrong again. On mips, we have 64-bit kernels with *three* different > possible userlands, n64, n32, and o32, and we do just fine (although as > of right now, we haven't bothered to make any n64 stages since they > would run slower than n32 and o32 on all of our supported hardware).
Where did you read the word 'mips' in my sentence above? Please, if this is just to make your boring evenings a bit more fun, try assing someone else.
Thanks in advance,
-- Simon Stelling Gentoo/AMD64 Operational Co-Lead bl...@gentoo.org -- gentoo-...@gentoo.org mailing list
On Thu, 2005-09-01 at 13:47 -0400, Mike Frysinger wrote: > On Thursday 01 September 2005 01:39 pm, Stephen P. Becker wrote: > > > There are too many packages that works *just* on x86, both at source and > > > binary level.
> > Doesn't the amd64 team have a set of 32-bit compat libs just to run > > binary packages? When running 32-bit code, isn't amd64 basically just a > > glorified athlon-xp?
> yes, assuming user wants that ... not everyone wants multilib crap on their > machine ... i know i'd prefer to have a 100% non-multilib system if i could > get away with it > -mike
Remember that some users still want to run 32bits apps and i think multilib is the best way to support both 32 and 64 bits. Our multilib implementation is far one of the best you can find out there. -- Luis Medinas <metal...@gentoo.org> http://dev.gentoo.org/~metalgod Gentoo Linux Developer: AMD64,Printing,app-cdr
Personally, I'd love to know what this proposed chunk of work and conflict is going to gain us...
Seen a fair amount of "you should", but no "and this is why". Without the latter, not seeing any reason we should collapse the two biggest arches into one (qa fun during it), considering the workload and points people have made.
Andrew Gaffney wrote: [Thu Sep 01 2005, 12:20:00PM CDT]
> Are you volunteering? :P
Absolutely not! I think it's an interesting discussion, and from what I understand about the implementation I am inclined to favor it, but I'm far from an expert (which is true for almost all of our devs, by the way). I'll happily leave writing such a GLEP to the people who actually are experts in this area, trusting them to properly educate the rest of us about exactly how it could work, and _then_ people can really make an informed decision.
On Thursday 01 September 2005 20:02, Ciaran McCreesh wrote:
> Take a look at how sparc and mips currently handle packages which will > run on some CPU kinds or ABIs but not others.
xine-lib, was not compiling on sparc32 (as there's a bug open), wasn't working on sparc64 (sigbus) until 1.1.0... all the versions are marked ~sparc ..
Why I still looking for REASONING to your "Untrue" specifically about
| While it can be simple to do for sparc or ppc that has relatively | less users, and with no need for binary compatibility for -bin | packages,
just to start from?
The *users* are the imporant part... mips and sparc are WAY far from the quantity of users of amd64 and x86... and the LEVEL of the users themselves, too!
