Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[gentoo-dev] combining x86 and amd64

22 views
Skip to first unread message

Grant Goodyear

unread,
Sep 1, 2005, 1:20:13 PM9/1/05
to
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?

-g2boojum-
--
Grant Goodyear
Gentoo Developer
g2bo...@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76

Simon Stelling

unread,
Sep 1, 2005, 1:30:09 PM9/1/05
to
Simon Stelling wrote:

> 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...

Gnah, forgot to include the link:

http://article.gmane.org/gmane.linux.gentoo.devel/26749/match=glep+++++amd64

You probably want to reuse this one, if you really like the idea, I for sure don't.


--
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
bl...@gentoo.org
--
gento...@gentoo.org mailing list

Andrew Gaffney

unread,
Sep 1, 2005, 1:30:12 PM9/1/05
to
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?

Are you volunteering? :P

--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Installer Project

--
gento...@gentoo.org mailing list

Diego 'Flameeyes' Pettenò

unread,
Sep 1, 2005, 1:30:18 PM9/1/05
to
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).

Please don't do that.

--
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)

Simon Stelling

unread,
Sep 1, 2005, 1:30:19 PM9/1/05
to
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...

--

Stephen P. Becker

unread,
Sep 1, 2005, 1:40:13 PM9/1/05
to
> 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.

-Steve
--
gento...@gentoo.org mailing list

Diego 'Flameeyes' Pettenò

unread,
Sep 1, 2005, 1:50:10 PM9/1/05
to
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?

Mike Frysinger

unread,
Sep 1, 2005, 1:50:11 PM9/1/05
to
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
--
gento...@gentoo.org mailing list

Ciaran McCreesh

unread,
Sep 1, 2005, 1:50:12 PM9/1/05
to
On Thu, 1 Sep 2005 19:23:38 +0200 "Diego 'Flameeyes' Pettenò"
<flam...@gentoo.org> 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...

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

--
gento...@gentoo.org mailing list

Stephen P. Becker

unread,
Sep 1, 2005, 1:50:16 PM9/1/05
to
> 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?

-Steve


--
gento...@gentoo.org mailing list

Simon Stelling

unread,
Sep 1, 2005, 1:50:17 PM9/1/05
to
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.

Stephen P. Becker

unread,
Sep 1, 2005, 2:00:12 PM9/1/05
to
> Also, you can't compare sparc32/sparc64 to x86/amd64: sparc64 is just a
> 64bit kernel with a 32bit userland.

Oh yeah, I forgot, sparc32 uses a different userland than sparc64 in
Gentoo. Shall I stop shooting holes in this type of argument now? :)

Stephen Bennett

unread,
Sep 1, 2005, 2:00:18 PM9/1/05
to
On Thu, 01 Sep 2005 19:42:46 +0200
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.
--
gento...@gentoo.org mailing list

Lares Moreau

unread,
Sep 1, 2005, 2:00:19 PM9/1/05
to
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?
>
> -g2boojum-

--
gento...@gentoo.org mailing list

Diego 'Flameeyes' Pettenò

unread,
Sep 1, 2005, 2:00:22 PM9/1/05
to
On Thursday 01 September 2005 19:41, Ciaran McCreesh wrote:
> Untrue.
Can I have reasoning?

Mike Frysinger

unread,
Sep 1, 2005, 2:00:26 PM9/1/05
to
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

Simon Stelling

unread,
Sep 1, 2005, 2:00:26 PM9/1/05
to
Stephen P. Becker wrote:
>> 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.

That's why I have another proposal: Let's merge x86 and amd64 keywords in about
10 years, when x86 died ;)

Stephen P. Becker

unread,
Sep 1, 2005, 2:00:27 PM9/1/05
to
> 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.

Stephen P. Becker

unread,
Sep 1, 2005, 2:00:28 PM9/1/05
to
Simon Stelling wrote:
> 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.

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).

Ciaran McCreesh

unread,
Sep 1, 2005, 2:10:09 PM9/1/05
to
On Thu, 1 Sep 2005 19:50:11 +0200 "Diego 'Flameeyes' Pettenò"
<flam...@gentoo.org> wrote:
| On Thursday 01 September 2005 19:41, Ciaran McCreesh wrote:
| > Untrue.
|
| Can I have reasoning?

Take a look at how sparc and mips currently handle packages which will
run on some CPU kinds or ABIs but not others.

Simon Stelling

unread,
Sep 1, 2005, 2:10:09 PM9/1/05
to
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,

Luis Medinas

unread,
Sep 1, 2005, 2:10:17 PM9/1/05
to

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 <meta...@gentoo.org>
http://dev.gentoo.org/~metalgod
Gentoo Linux Developer: AMD64,Printing,app-cdr

--
gento...@gentoo.org mailing list

Brian Harring

unread,
Sep 1, 2005, 2:20:06 PM9/1/05
to
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.

~harring

Grant Goodyear

unread,
Sep 1, 2005, 2:20:08 PM9/1/05
to
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.

Diego 'Flameeyes' Pettenò

unread,
Sep 1, 2005, 2:20:09 PM9/1/05
to
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!

Chris Gianelloni

unread,
Sep 1, 2005, 2:30:24 PM9/1/05
to

No. It just has the same *instruction* set as an Athlon XP, plus SSE2
and even SSE3 in newer models. There's also the Intel EM64T stuff which
is more like a P4 than an Athlon XP, since it has no 3Dnow! support.

--
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

signature.asc

Ciaran McCreesh

unread,
Sep 1, 2005, 2:40:07 PM9/1/05
to
On Thu, 1 Sep 2005 20:11:09 +0200 "Diego 'Flameeyes' Pettenò"
<flam...@gentoo.org> wrote:
| 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 ..

Ideally they wouldn't be keyworded at all.

| 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?

More users means more QA feedback. This means x86/amd64 will have an
*easier* job. And, uh, there are people out there shipping binaries for
sparc and mips.

| 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!

Again, more users means more QA feedback. Other than that, the users
won't see any difference except for the profile they use.

Olivier Crete

unread,
Sep 1, 2005, 2:40:12 PM9/1/05
to
On Thu, 2005-01-09 at 19:02 +0100, Ciaran McCreesh wrote:
> On Thu, 1 Sep 2005 19:50:11 +0200 "Diego 'Flameeyes' Pettenò"
> <flam...@gentoo.org> wrote:
> | On Thursday 01 September 2005 19:41, Ciaran McCreesh wrote:
> | > Untrue.
> |
> | Can I have reasoning?
>
> Take a look at how sparc and mips currently handle packages which will
> run on some CPU kinds or ABIs but not others.

Is it just me, it seems that only sparc/mips devs want that kind of
change and non none of the x86/amd64 devs...

I still dont see what practical advantage that would bring to x86/amd64
users or developers?

--
Olivier Crête
tes...@gentoo.org
Gentoo Developer
x86 Security Liaison


--
gento...@gentoo.org mailing list

Ciaran McCreesh

unread,
Sep 1, 2005, 2:50:07 PM9/1/05
to
On Thu, 01 Sep 2005 14:36:44 -0400 Olivier Crete <tes...@gentoo.org>
wrote:

| Is it just me, it seems that only sparc/mips devs want that kind of
| change and non none of the x86/amd64 devs...

The people who have worked with such a system before and understand how
it works and what all it can do want change. Those who don't understand
the system and think that it has all kinds of problems that are really
just a lack of understanding don't want it to change.

| I still dont see what practical advantage that would bring to
| x86/amd64 users or developers?

QA.

Diego 'Flameeyes' Pettenò

unread,
Sep 1, 2005, 2:50:05 PM9/1/05
to
On Thursday 01 September 2005 20:32, Ciaran McCreesh wrote:
> Ideally they wouldn't be keyworded at all.
I live in a real world, not an ideal one.

> More users means more QA feedback. This means x86/amd64 will have an
> *easier* job.

SNR, this unknown value that's so much important in communications... this is
when I like the school I did.

> And, uh, there are people out there shipping binaries for
> sparc and mips.

http://packages.gentoo.org/search/?sstring=mozilla-bin
http://packages.gentoo.org/search/?sstring=openoffice-bin
http://packages.gentoo.org/search/?sstring=realplayer
http://packages.gentoo.org/search/?sstring=acroread
http://packages.gentoo.org/search/?sstring=netscape-flash

Want some others?

> Again, more users means more QA feedback. Other than that, the users
> won't see any difference except for the profile they use.

SNR...

Ciaran McCreesh

unread,
Sep 1, 2005, 2:50:12 PM9/1/05
to
On Thu, 1 Sep 2005 12:10:28 -0500 Grant Goodyear <g2bo...@gentoo.org>

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?

Won't work. Too many people who don't have a clue what's being proposed
and who don't understand the explanations.

Ciaran McCreesh

unread,
Sep 1, 2005, 3:00:17 PM9/1/05
to
On Thu, 1 Sep 2005 20:46:46 +0200 "Diego 'Flameeyes' Pettenò"
<flam...@gentoo.org> wrote:
| On Thursday 01 September 2005 20:32, Ciaran McCreesh wrote:
| > Ideally they wouldn't be keyworded at all.
| I live in a real world, not an ideal one.
|
| > More users means more QA feedback. This means x86/amd64 will have an
| > *easier* job.
| SNR, this unknown value that's so much important in communications...
| this is when I like the school I did.

So your argument is that our users are clueless morons?
Explain to me how this cannot be solved via the profile arch system
plus use_expand.

Mike Doty

unread,
Sep 1, 2005, 3:00:20 PM9/1/05
to
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?
>
> -g2boojum-

This will not happen. Years down the road AMD64 may absorb the
remaining x86 issues, but AMD64 will certainly never be run like x86 has
been.

Mike Doty
--
gento...@gentoo.org mailing list

Stephen P. Becker

unread,
Sep 1, 2005, 3:00:21 PM9/1/05
to
> Is it just me, it seems that only sparc/mips devs want that kind of
> change and non none of the x86/amd64 devs...
>
> I still dont see what practical advantage that would bring to x86/amd64
> users or developers?

If you haven't figured out the reason we are pushing for this sort of
thing yet, it is because x86 is unsupported in Gentoo (if you consider
what all the other arches have to do to be "supported"). As a result,
it causes the quality of the portage tree to suffer. Time and time
again, it has been brought up that x86 should have an arch team, yet
nobody ever acts on it. Well, merging the "two" arches will help solve
this problem.

Diego 'Flameeyes' Pettenò

unread,
Sep 1, 2005, 3:00:22 PM9/1/05
to
On Thursday 01 September 2005 20:42, Ciaran McCreesh wrote:
> The people who have worked with such a system before and understand how
> it works and what all it can do want change. Those who don't understand
> the system and think that it has all kinds of problems that are really
> just a lack of understanding don't want it to change.
The firsts includes the ones that REALLY works with x86 and amd64.
The latter don't give a damn about x86 and amd64 and seems just like they want
to show off how much they are better than us...

> QA.
SNR

Martin Schlemmer

unread,
Sep 1, 2005, 3:10:10 PM9/1/05
to
On Thu, 2005-09-01 at 14:36 -0400, Olivier Crete wrote:
> On Thu, 2005-01-09 at 19:02 +0100, Ciaran McCreesh wrote:
> > On Thu, 1 Sep 2005 19:50:11 +0200 "Diego 'Flameeyes' Pettenò"
> > <flam...@gentoo.org> wrote:
> > | On Thursday 01 September 2005 19:41, Ciaran McCreesh wrote:
> > | > Untrue.
> > |
> > | Can I have reasoning?
> >
> > Take a look at how sparc and mips currently handle packages which will
> > run on some CPU kinds or ABIs but not others.
>
> Is it just me, it seems that only sparc/mips devs want that kind of
> change and non none of the x86/amd64 devs...
>

No, Yes, and Yes.

> I still dont see what practical advantage that would bring to x86/amd64
> users or developers?
>

Well, I guess the theory might be because then you only have one keyword
and one base profile to manage - I think.

---

From a quick diff, it looks like they are handled via the ABI and
PROFILE_ARCH stuff, but what your average sparc/mips dev do not realise,
is that most x86 devs, and probably many amd64 devs have no idea what
and how the ABI stuff is used. Mostly the ABI stuff was hacked by (and
still is mostly if I'm not mistaken) by Jeremy, and they mostly just use
ARCH or use to apply x86/amd64 patches.

So your basic problem is that:
1) They have no idea how sparc/mips does it
2) They do not see any benefits
3) They get even more confused by the half assed answers they get.

So to be frank, I propose that either the alt-arch devs start explaining
above instead of half-assed answers and senseless ranting, or shut up.
From the amount of _usefull_ comments they have given, it does not look
like its really an issue or priority for them besides having some fun.


Thanks,

--
Martin Schlemmer

signature.asc

Ciaran McCreesh

unread,
Sep 1, 2005, 3:10:11 PM9/1/05
to
On Thu, 1 Sep 2005 20:54:15 +0200 "Diego 'Flameeyes' Pettenò"
<flam...@gentoo.org> wrote:
| On Thursday 01 September 2005 20:42, Ciaran McCreesh wrote:
| > The people who have worked with such a system before and understand
| > how it works and what all it can do want change. Those who don't
| > understand the system and think that it has all kinds of problems
| > that are really just a lack of understanding don't want it to
| > change.
| The firsts includes the ones that REALLY works with x86 and amd64.

The ones who are short-sighted and only understand simple non-split
archs, yes.

| The latter don't give a damn about x86 and amd64 and seems just like
| they want to show off how much they are better than us...
|
| > QA.
| SNR

Note the 'ratio' part. It isn't affected by a change in the number of
users.

Martin Schlemmer

unread,
Sep 1, 2005, 3:10:12 PM9/1/05
to
On Thu, 2005-09-01 at 19:42 +0100, Ciaran McCreesh wrote:
> On Thu, 01 Sep 2005 14:36:44 -0400 Olivier Crete <tes...@gentoo.org>
> wrote:
> | Is it just me, it seems that only sparc/mips devs want that kind of
> | change and non none of the x86/amd64 devs...
>
> The people who have worked with such a system before and understand how
> it works and what all it can do want change. Those who don't understand
> the system and think that it has all kinds of problems that are really
> just a lack of understanding don't want it to change.
>

Maybe, but please give one example of such an 'explanation' that any of
the pro-merge devs have given.

> | I still dont see what practical advantage that would bring to
> | x86/amd64 users or developers?
>
> QA.

Possible, but once again, why will a merge give 'better' QA ?


--
Martin Schlemmer

signature.asc

Olivier Crete

unread,
Sep 1, 2005, 3:10:13 PM9/1/05
to
On Thu, 2005-01-09 at 19:53 +0100, Ciaran McCreesh wrote:
> On Thu, 1 Sep 2005 20:46:46 +0200 "Diego 'Flameeyes' Pettenò"
> <flam...@gentoo.org> wrote:
> | On Thursday 01 September 2005 20:32, Ciaran McCreesh wrote:
> | > Ideally they wouldn't be keyworded at all.
> | I live in a real world, not an ideal one.
> |
> | > More users means more QA feedback. This means x86/amd64 will have an
> | > *easier* job.
> | SNR, this unknown value that's so much important in communications...
> | this is when I like the school I did.
>
> So your argument is that our users are clueless morons?

Many of the x86/amd64 user are... many like reiser4.. some even use
love-sources...

Grant Goodyear

unread,
Sep 1, 2005, 3:10:13 PM9/1/05
to
Ciaran McCreesh wrote: [Thu Sep 01 2005, 01:41:22PM CDT]

> Won't work. Too many people who don't have a clue what's being proposed
> and who don't understand the explanations.

Okay, with that statement, and an inability to find anybody else who
really wants to write such a GLEP, I'm certainly willing to drop it.

Diego 'Flameeyes' Pettenò

unread,
Sep 1, 2005, 3:20:07 PM9/1/05
to
On Thursday 01 September 2005 21:02, Ciaran McCreesh wrote:
> Note the 'ratio' part. It isn't affected by a change in the number of
> users.
sparc users = few, but most of them are literate
x86 users = a lot, most of the illiterate, ricer, ranting users..

the ratio means that we have more eyes, but more of them are noise...

Ciaran McCreesh

unread,
Sep 1, 2005, 3:20:12 PM9/1/05
to
On Thu, 01 Sep 2005 20:59:01 +0200 Martin Schlemmer <aza...@gentoo.org>
wrote:

| So to be frank, I propose that either the alt-arch devs start
| explaining above instead of half-assed answers and senseless ranting,
| or shut up. From the amount of _usefull_ comments they have given, it
| does not look like its really an issue or priority for them besides
| having some fun.

Hence the GLEP proposal. Unfortunately, too many ignorant people are
jumping in and spewing out nonsense about things they don't understand
before the GLEP's even written...

Diego 'Flameeyes' Pettenò

unread,
Sep 1, 2005, 3:20:15 PM9/1/05
to
On Thursday 01 September 2005 20:54, Stephen P. Becker wrote:
> Well, merging the "two" arches will help solve
> this problem.
I read this as "as nobody wants to take care of x86, and we can't blame anyone
because there's no one to blame, let make amd64 arch team the one to blame",
as we don't have facts about x86 arch team at all.

Diego 'Flameeyes' Pettenò

unread,
Sep 1, 2005, 3:20:20 PM9/1/05
to
On Thursday 01 September 2005 21:00, Martin Schlemmer wrote:
> Possible, but once again, why will a merge give 'better' QA ?
Because you start over. You have to DO actually the QA that's missing on x86.
That's true but... WHO will do that?
The new "merged" arch team... but let my math skills try to solve this

a + b = c

x86 arch team + amd64 arch team = combined arch team

0 + b = b

x86 arch team = 0

and this means that AMD64 arch team will have to do QA for x86, too...
Yeah "someone will join" ... but I want to have a list of people joining
before say that "someone will join"...

Ciaran McCreesh

unread,
Sep 1, 2005, 3:30:11 PM9/1/05
to
On Thu, 1 Sep 2005 21:19:31 +0200 "Diego 'Flameeyes' Pettenò"
<flam...@gentoo.org> wrote:
| On Thursday 01 September 2005 21:09, Ciaran McCreesh wrote:
| > Hence the GLEP proposal. Unfortunately, too many ignorant people are
| > jumping in and spewing out nonsense about things they don't
| > understand before the GLEP's even written...
| There was one, wasn't it? And I think I answered to that with some
| points. I have explained my reasons for not doing so today.

No, there was an April Fool's joke.

Simon Stelling

unread,
Sep 1, 2005, 3:30:12 PM9/1/05
to
Martin Schlemmer wrote:
>>I still dont see what practical advantage that would bring to x86/amd64
>>users or developers?
>>
>
>
> Well, I guess the theory might be because then you only have one keyword
> and one base profile to manage - I think.

Having just one keyword won't decrease our (our as in amd64 team) workload, nor
will it increase our (our as in amd64 port) QA, it will just be the other way
around. What really is confusing me is that mostly sparc/mips-devs want to push
us in a direction we absolutely don't like, but we're affected by all effects,
not them. And what is even more confusing, is that they make statements like

"I don't care about x86/amd64"

> So to be frank, I propose that either the alt-arch devs start explaining
> above instead of half-assed answers and senseless ranting, or shut up.
> From the amount of _usefull_ comments they have given, it does not look
> like its really an issue or priority for them besides having some fun.

So I'm not the only one feeling assed, fine. I know ABI, but only in the context
of multilib. We use it to decide whether something is 32bit or 64bit.
As stated above, I can see how x86 will benefit from a merge, but the damage
amd64 gets seems far bigger.

Diego 'Flameeyes' Pettenò

unread,
Sep 1, 2005, 3:30:14 PM9/1/05
to
On Thursday 01 September 2005 21:09, Ciaran McCreesh wrote:
> Hence the GLEP proposal. Unfortunately, too many ignorant people are
> jumping in and spewing out nonsense about things they don't understand
> before the GLEP's even written...
There was one, wasn't it? And I think I answered to that with some points.
I have explained my reasons for not doing so today.
I have received no answer to those reasons that was not "QA", "more eyes means
better" and "x86 arch team", to which I already have answered...

Chris Gianelloni

unread,
Sep 1, 2005, 3:30:17 PM9/1/05
to

So would just making an x86 arch team. It would also be much less of a
problem than merging x86 and amd64. How about this? I proclaim and x86
arch team now exists. It already has a security liason.

$ cat /var/mail/alias/arch/x86
avenj
solar
tester
port001
azarah

Seems that we even have two of our new Council members on the team.
Anybody else want to join the team? Just add yourself to the alias and
start paying attention to requests that are submitted to x...@gentoo.org
via bugzilla.

Somehow, I find that infinitely easier to implement than being forced
into grouping together two KEYWORDS, that while technically possible to
merge, would be a logistical nightmare due to limitations in our current
developer pool's knowledge.

signature.asc

Chris Gianelloni

unread,
Sep 1, 2005, 3:40:08 PM9/1/05
to
On Thu, 2005-09-01 at 21:17 +0200, Diego 'Flameeyes' Pettenò wrote:
> The new "merged" arch team... but let my math skills try to solve this
>
> a + b = c
>
> x86 arch team + amd64 arch team = combined arch team
>
> 0 + b = b
>
> x86 arch team = 0
>
> and this means that AMD64 arch team will have to do QA for x86, too...

Hehehe... I like this explanation. It is very simple, but it does show
part of the problem of such a merge.

signature.asc

Chris Gianelloni

unread,
Sep 1, 2005, 3:40:11 PM9/1/05
to
On Thu, 2005-09-01 at 21:14 +0200, Diego 'Flameeyes' Pettenò wrote:
> x86 users = a lot, most of the illiterate, ricer, ranting users..

I thought that was amd64? :P

Anyway, here's what *I* propose. I propose that we all just shut up and
ignore this. It's obvious that there's not going to be an agreement on
it, so let's drop it until there's an actual GLEP written on it. At
that point, you can argue the points of the GLEP and it won't just be
useless flaming.

Either that, or you can take your stand and join up to form an x86 arch
team and just end the need for this discussion right now.

signature.asc

Diego 'Flameeyes' Pettenò

unread,
Sep 1, 2005, 3:40:12 PM9/1/05
to
On Thursday 01 September 2005 21:29, Chris Gianelloni wrote:
> I thought that was amd64?  
Well.. it actually is both :)

Diego 'Flameeyes' Pettenò

unread,
Sep 1, 2005, 3:50:06 PM9/1/05
to
On Thursday 01 September 2005 21:28, Ciaran McCreesh wrote:
> | There was one, wasn't it? And I think I answered to that with some
> | points. I have explained my reasons for not doing so today.
> No, there was an April Fool's joke.
Have to look down to the irc logs to find you said you were serious? That's
why I pointed to that.
If you weren't, well I'm sorry I pointed to that, please next time be more
explicit with april fools... and now provide me an explaination, a solution,
or something :)

Simon Stelling

unread,
Sep 1, 2005, 3:50:09 PM9/1/05
to
Ciaran McCreesh wrote:
> No, there was an April Fool's joke.

Which pretty good shows how ridiculous such a merge would be...

Ciaran McCreesh

unread,
Sep 1, 2005, 4:10:20 PM9/1/05
to
On Thu, 01 Sep 2005 21:42:09 +0200 Simon Stelling <bl...@gentoo.org>
wrote:

| Ciaran McCreesh wrote:
| > No, there was an April Fool's joke.
|
| Which pretty good shows how ridiculous such a merge would be...

Not at all. It showed just how many silly knee-jerk reactions such a
proposal would get.

Ian Leitch

unread,
Sep 1, 2005, 4:20:18 PM9/1/05
to
I think myself and tester are the only members who can be considered
active at the moment. I'm happy with creating an arch team, though I
don't think we'll end up with an abundance of members (x86 is far from
the most popular arch among devs).

Chris Gianelloni wrote:
> So would just making an x86 arch team. It would also be much less of a
> problem than merging x86 and amd64. How about this? I proclaim and x86
> arch team now exists. It already has a security liason.
>
> $ cat /var/mail/alias/arch/x86
> avenj
> solar
> tester
> port001
> azarah

--
gento...@gentoo.org mailing list

Kevin F. Quinn

unread,
Sep 1, 2005, 4:30:20 PM9/1/05
to

Surely ths solution to that problem is to set up an x86 arch team, not to put such big a millstone around the neck of the amd64 team.

--
gento...@gentoo.org mailing list

Martin Schlemmer

unread,
Sep 1, 2005, 4:40:10 PM9/1/05
to
On Thu, 2005-09-01 at 21:14 +0100, Ian Leitch wrote:
> I think myself and tester are the only members who can be considered
> active at the moment. I'm happy with creating an arch team, though I
> don't think we'll end up with an abundance of members (x86 is far from
> the most popular arch among devs).
>

Yeah, I added myself not too long back, but I still need to get my P4 up
and running .. should be in the next week or two.

> Chris Gianelloni wrote:
> > So would just making an x86 arch team. It would also be much less of a
> > problem than merging x86 and amd64. How about this? I proclaim and x86
> > arch team now exists. It already has a security liason.
> >
> > $ cat /var/mail/alias/arch/x86
> > avenj
> > solar
> > tester
> > port001
> > azarah

--
Martin Schlemmer

signature.asc

Danny van Dyk

unread,
Sep 1, 2005, 4:50:08 PM9/1/05
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh schrieb:
| On Thu, 1 Sep 2005 12:10:28 -0500 Grant Goodyear <g2bo...@gentoo.org>


| 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?
|

| Won't work. Too many people who don't have a clue what's being proposed
| and who don't understand the explanations.

Too many people out of other projects try to achieve changes they want
and put them on other people's todo lists...

Danny
- --
Danny van Dyk <kuge...@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDF2ohaVNL8NrtU6IRAunnAJ4zdz33d0M6HghkrD4bWV+c86454ACgo0yq
058mbbrLLtkAgMRKlZA3xJY=
=gZa5
-----END PGP SIGNATURE-----
--
gento...@gentoo.org mailing list

Danny van Dyk

unread,
Sep 1, 2005, 4:50:10 PM9/1/05
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mike,

Mike Frysinger schrieb:
| 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
You can, we have the 'no-multilib' subprofile, and there is still
hardened/amd64 which is not multilib, either.

| -mike

Danny
- --
Danny van Dyk <kuge...@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDF2i8aVNL8NrtU6IRAgUmAJ4n5zQAzqPYuoI3xakYxz+YLYCqIwCfZrUt
L7WHl+Z77EmD+e1tkufHEbE=
=0Dwc

Olivier Crete

unread,
Sep 1, 2005, 5:10:13 PM9/1/05
to
On Thu, 2005-01-09 at 15:25 -0400, Chris Gianelloni wrote:
> So would just making an x86 arch team. It would also be much less of a
> problem than merging x86 and amd64. How about this? I proclaim and x86
> arch team now exists. It already has a security liason.
>
> $ cat /var/mail/alias/arch/x86
> avenj
> solar
> tester
> port001
> azarah
>
> Seems that we even have two of our new Council members on the team.
> Anybody else want to join the team? Just add yourself to the alias and
> start paying attention to requests that are submitted to x...@gentoo.org
> via bugzilla.

The people maintaining the x86 kernel should also join, as well as the
release maintainer (chris, is that you?), the grub/lilo maintainers,
etc... That would be a good start.

We should also try to recruit one or two x86 arch testers, hparker has
offered to help.

Daniel Gryniewicz

unread,
Sep 1, 2005, 5:20:15 PM9/1/05
to
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?
>
> -g2boojum-

Just out of curiousity, what makes people think that the amd64 team will
sit still for having all of x86 foisted off on them?
--
Daniel Gryniewicz
Gentoo AMD64 Team

--
gento...@gentoo.org mailing list

Luis F. Araujo

unread,
Sep 1, 2005, 5:50:17 PM9/1/05
to
Stephen P. Becker wrote:

>> Is it just me, it seems that only sparc/mips devs want that kind of
>> change and non none of the x86/amd64 devs...
>> I still dont see what practical advantage that would bring to x86/amd64
>> users or developers?
>
>
> If you haven't figured out the reason we are pushing for this sort of
> thing yet, it is because x86 is unsupported in Gentoo (if you consider
> what all the other arches have to do to be "supported"). As a result,
> it causes the quality of the portage tree to suffer.

You are saying that the quality of x86 stuff in the tree is worse than
the other arches?

--
gento...@gentoo.org mailing list

Chris Gianelloni

unread,
Sep 1, 2005, 6:10:10 PM9/1/05
to
On Thu, 2005-09-01 at 17:05 -0400, Olivier Crete wrote:
> release maintainer (chris, is that you?), the grub/lilo maintainers,

Currently, yes.

I'll add myself to the alias.

signature.asc

Christian Parpart

unread,
Sep 1, 2005, 6:50:03 PM9/1/05
to
On Thursday 01 September 2005 19:10, 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.

aha? Not in the list, is it?

> 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?

This just leads me to assume you're not really a coder (wrt native programming
languages like C/C++), are you?

I mean, x86 (32bit) and amd64 (64bit) ARE NOT THE SAME ARCH.
This is simply demonstrated by all those ugly pointer-to-integer conversions
that often happen when you write on your legacy x86 architecture.
However, when you try to compile it on an amd64 e.g., you just can't as gcc
WILL bail out.
Having now a x86amd64-alike keyword instead of x86 and amd64 will just make
lots of user's emerge experiences pain ass.
Of course, OTOH, while our bugs db gets flooded with reports, this *could* be
a startup for us to know *what* packages needs fixing. But that way, we would
be jast far off enterprise.

Here's an example that works on x86 but *not* an amd64:

// g++ -o test32vs64bit test32vs64bit.cpp
#include <cstdlib>

int main() {
void *p = NULL;
unsigned u = (unsigned)p; // ok on x86; error on amd64

p = (void *)u; // ok on x86; error on amd64

return 0;
}

Of course, you might think WTF do some guy need this, but hey, programmers are
really creative, and use what the compiler accepts - I myself ran into this
while porting my apps/libs to amd64. And think of it, not everybody has the
money to grab one.

Congrats,
Christian Parpart.

Grant Goodyear

unread,
Sep 1, 2005, 9:40:06 PM9/1/05
to
Christian Parpart wrote: [Thu Sep 01 2005, 05:45:43PM CDT]

> This just leads me to assume you're not really a coder (wrt native
> programming languages like C/C++), are you?

*Grin* This sort of condescending attitude is rarely wise when it comes
to dealing with Gentoo devs. Not only does it tend to annoy people
(yes, I'm a tad annoyed by the presumption), but since you're still
relatively new here the odds are that people know the person you're
being condescending to better than they know you, and thus it just makes
you look bad if you're wrong. Feel free to ask people what I do for a
living, and whether they suspect that I know the difference between a
64-bit pointer and a 32-bit int.

Best,
g2boojum

Luis Medinas

unread,
Sep 1, 2005, 10:00:09 PM9/1/05
to
On Thu, 2005-09-01 at 17:05 -0400, Olivier Crete wrote:
> On Thu, 2005-01-09 at 15:25 -0400, Chris Gianelloni wrote:
> > So would just making an x86 arch team. It would also be much less of a
> > problem than merging x86 and amd64. How about this? I proclaim and x86
> > arch team now exists. It already has a security liason.
> >
> > $ cat /var/mail/alias/arch/x86
> > avenj
> > solar
> > tester
> > port001
> > azarah
> >
> > Seems that we even have two of our new Council members on the team.
> > Anybody else want to join the team? Just add yourself to the alias and
> > start paying attention to requests that are submitted to x...@gentoo.org
> > via bugzilla.
>
> The people maintaining the x86 kernel should also join, as well as the
> release maintainer (chris, is that you?), the grub/lilo maintainers,
> etc... That would be a good start.
>
> We should also try to recruit one or two x86 arch testers, hparker has
> offered to help.
Be ready to test my packages has well. I'm very happy with the formation
of the new x86 arch team i wish you the best and i think this is the way
to improve Gentoo (QA, releases etc..).
You guys need a doc writer too (catch one at #-doc)
And of course i think AT's will have much work to do on the x86 team.
--
Luis Medinas <meta...@gentoo.org>
http://dev.gentoo.org/~metalgod
Gentoo Linux Developer: AMD64,Printing,Media-Optical

--
gento...@gentoo.org mailing list

Luis Medinas

unread,
Sep 1, 2005, 10:00:09 PM9/1/05
to
I belive that's a reality. For example on AMD64 devs and AT's tested the
new 2005.1 livecd and stages for long time. On our team we found bugs on
packages (missing deps or patches) and we also test the packages with
the help of our AT's. At this moment i belive that x86 really misses the
arch team (hopefully it's in formation) to help test, improve QA and
also take care of security issues for example.

Lance Albertson

unread,
Sep 2, 2005, 12:30:13 AM9/2/05
to
Grant Goodyear wrote:
> Christian Parpart wrote: [Thu Sep 01 2005, 05:45:43PM CDT]
>
>>This just leads me to assume you're not really a coder (wrt native
>>programming languages like C/C++), are you?
>
>
> *Grin* This sort of condescending attitude is rarely wise when it comes
> to dealing with Gentoo devs. Not only does it tend to annoy people
> (yes, I'm a tad annoyed by the presumption), but since you're still
> relatively new here the odds are that people know the person you're
> being condescending to better than they know you, and thus it just makes
> you look bad if you're wrong. Feel free to ask people what I do for a
> living, and whether they suspect that I know the difference between a
> 64-bit pointer and a 32-bit int.

Ha! Yeah ... kids these days... just don't respect their elders like
they should ;-). I have seen more and more 'newish' devs speaking their
minds like this without even knowing/asking the person. I guess respect
and tactfulness isn't being taught anymore...

And yes, Grant definitely knows the difference :-)

Cheers,

--
Lance Albertson <rame...@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key: <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

signature.asc

Mike Doty

unread,
Sep 2, 2005, 8:30:23 AM9/2/05
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Grant Goodyear wrote:
| Christian Parpart wrote: [Thu Sep 01 2005, 05:45:43PM CDT]
|
|>This just leads me to assume you're not really a coder (wrt native
|>programming languages like C/C++), are you?
|
|
| *Grin* This sort of condescending attitude is rarely wise when it comes
| to dealing with Gentoo devs. Not only does it tend to annoy people
| (yes, I'm a tad annoyed by the presumption), but since you're still
| relatively new here the odds are that people know the person you're
| being condescending to better than they know you, and thus it just makes
| you look bad if you're wrong. Feel free to ask people what I do for a
| living, and whether they suspect that I know the difference between a
| 64-bit pointer and a 32-bit int.

You would be suprised how many people assume they can safely cast
pointers into ints and back. Thankfully, this is finally on the decline.

- --
=======================================================
Mike Doty king...@gentoo.org
Gentoo/AMD64 Strategic Lead PGP Key: 0xA797C7A7
Gentoo Developer Relations
~ ===GPG Fingerprint===
~ 0094 7F06 913E 78D6 F1BB 06BA D0AD D125 A797 C7A7
=======================================================


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDGETR0K3RJaeXx6cRAjVYAJsE9j6GTr8DqUWSAnNqoZ+XikN2BQCfSGKh
NKUpUoThUYE9aZ3rHLuHsoc=
=frbO

splite...@sigint.cs.purdue.edu

unread,
Sep 2, 2005, 3:40:11 PM9/2/05
to
On Thu, Sep 01, 2005 at 07:42:46PM +0200, Simon Stelling wrote:
>
> 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.

Actually, what I want is a 32-bit x86 userland with a 64-bit kernel and
multilib'd gcc, bintools, and glibc. In other words, a 32-bit userland
that my users can still compile and run their 64-bit number crunchers on.
They don't need 64-bit X11, KDE, GNOME, etc. They do, however, want their
Flash and Acroread plugins to work.

I've kludged together such a system by hand and it's quite nice. Browser
plugins and binary-only programs (StarOffice, etc.) work as expected.
gcc defaults to building 32-bit binaries that still work on my users'
older systems, but a quick "-m64" will deliver the 64-bit goodness (use
as directed.)

Anyone have a way of doing this that doesn't involve wholesale plundering
of binaries from an amd64 box? Some funky bouillabaisse of use flags,
profiles, and gcc hoodoo? Or am I the only one who thinks this is a pretty
neat idea (digital watches notwithstanding)?
--
gento...@gentoo.org mailing list

Duncan

unread,
Sep 3, 2005, 12:00:10 AM9/3/05
to
splite-gentoo posted <2005090219...@sigint.cs.purdue.edu>,
excerpted below, on Fri, 02 Sep 2005 14:33:22 -0500:

> Actually, what I want is a 32-bit x86 userland with a 64-bit kernel and
> multilib'd gcc, bintools, and glibc. In other words, a 32-bit userland
> that my users can still compile and run their 64-bit number crunchers on.
> They don't need 64-bit X11, KDE, GNOME, etc. They do, however, want their
> Flash and Acroread plugins to work.
>

> Anyone have a way of doing this that doesn't involve wholesale plundering

> of binaries from an amd64 box? [] Or am I the only one who thinks this


> is a pretty neat idea (digital watches notwithstanding)?

Disclaimer, I'm a Gentoo AMD64 user, not a dev...

It's a neat idea, but might not be quite the "best of both worlds" you
may well believe you are getting. Perhaps you are aware of the following
and believe full 32-bit compatibility is easier (if a bit more hassle due
to the "by hand" you mention). If so, great, be it far from me to say
you have it wrong when I don't know the specifics of your installation; if
not, a slightly different alternative, as explained, might be better, and
certainly easier given that you wouldn't have the "by hand" stuff. Even
if you still want a mostly 32-bit userland, there's a solution below that
should be less hassle than what you describe as your current one.

In general, you are quite correct, 64-bit doesn't normally offer that much
other than flatter memory access and better number crunching in certain
situations. On pretty much any bi-arch other than amd64, your solution
would be perfect.

However, the x86/amd64 performance difference is somewhat larger than
that, due to x86 architectural peculiarities. The biggest of these is
x86's relative lack of named registers, as compared to other modern
architectures. 64-bit AMD64 addresses this weakness by adding additional
registers. However, for compatibility reasons, these registers aren't
available in 32-bit mode, only in 64-bit mode.

The result is that while (admittedly pulling numbers out of the air for
demonstration's sake, the argument is sound, do your own research on
specific numbers, if desired) 60 or 70 percent of apps on most archs would
get little benefit from switching to 64-bit, but would instead actually
lose performance due to the additional memory requirements of 64-bit over
32-bit, on AMD64, the same 60 or 70 percent will likely see improvements,
despite the larger working size and memory requirements, due to use of the
additional registers. Efficiency can be increased somewhat further with
-frename-registers and similar tricks to make better use of all available
registers.

Due primarily to the "register factor", it thus makes better sense to run
a general 64-bit userland than it might on other platforms, and this is
what Gentoo for AMD64 is designed for, for the most part. Gentoo AMD64's
multilib setup makes it possible to run the 32-bit binary-only apps, and
from-source 32-bit apps with 32-bit binary-only codecs and plugins, that
you may need, while at the same time being designed "out of the box" (or
should that be "from the profile"??) to run a general 64-bit userland
where 32-bit is /not/ necessary, because that's generally most efficient
for the reasons explained above.

Note, however, that you still have a couple of options, one of which
would end up pretty close to what you describe, only without the "by hand"
hassle you have at the moment.

The normal profile and setup is designed, as already mentioned, to
emphasize 64-bit. However, on top of that, while it enables 32-bit, it is
designed to emphasize minimal-maintenance-hassle 32-bit, over maximum
run-time-efficency 32-bit. A number of the 32-bit compatibility libraries
are by default binaries, of less optimization than normal, because they
are designed to run on both ia64 (Itanium) and amd64. Likewise with the
32-bit binary applications such as mozilla-firefox-bin, if you choose to
install them.

Note that due to portage limitations (it can't track 32-bit and 64-bit
dependencies separately at this time) it's not wise to use the 64-bit
system-wide portage to install 32-bit stuff (other than the 32-bit
binary-only stuff). However, you still have options...

For those that want optimized 32-bit, the recommended solution is to run a
32-bit chroot. There are instructions in the amd64 technotes, but the
idea is that after you set up your 64-bit system, you setup a 32-bit
chroot. In it, you setup a 32-bit profile and generally emerge anything
you want 32-bit, including all dependencies, in that profile. Because
you are running a separate 32-bit only copy of portage, with its own
database, in the chroot, it won't interfere with the 64-bit main system
copy.

Now, normally, one would still run a mostly 64-bit system, including
whatever system daemons (cron, syslog, etc) and general applications one
would normally be running, presumably only merging applications that had
32-bit-binary-only dependencies (along with the from-source
dependencies, in 32-bit form as well) in the chroot. However, there's
really nothing stopping you from merging and running most of your system
as 32-bit, with the 64-bit "main" system being only a minimal base, if
that's what you prefer. Given the "register factor" above, however, IMUO
(U=user), it still makes more sense to run the general system as 64-bit,
on amd64, and only run 32-bit where necessary for compatibility reasons.
However, that's just "MUO" and "YUO" may well be quite different. Since
it's your boxen we are talking about, it's "YUO" that applies. =8^)

Finally, this should have really been posted to the amd64 list, not the
devel list, thus not bothering all the devels who don't do AMD64. There
are many there, both users and devs, quite willing to help, and it's
certainly more a topic for there than for here. So... while Gentoo devs
are usually pretty nice about answering anyway, and I'm replying here as
well so maybe they won't have to and can keep doing the good things they
do as devs bringing us all those nice ebuilds to play with =8^), please...
for any followups and for next time, post gentoo-amd64 questions to the
gentoo-amd64 list, OK? That's what it's there for. =8^)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gento...@gentoo.org mailing list

Christian Parpart

unread,
Sep 4, 2005, 5:10:05 AM9/4/05
to
On Friday 02 September 2005 06:28, Lance Albertson wrote:
> Grant Goodyear wrote:
> > Christian Parpart wrote: [Thu Sep 01 2005, 05:45:43PM CDT]
> >
> >>This just leads me to assume you're not really a coder (wrt native
> >>programming languages like C/C++), are you?
> >
> > *Grin* This sort of condescending attitude is rarely wise when it comes
> > to dealing with Gentoo devs. Not only does it tend to annoy people
> > (yes, I'm a tad annoyed by the presumption), but since you're still
> > relatively new here the odds are that people know the person you're
> > being condescending to better than they know you, and thus it just makes
> > you look bad if you're wrong. Feel free to ask people what I do for a
> > living, and whether they suspect that I know the difference between a
> > 64-bit pointer and a 32-bit int.
>
> Ha! Yeah ... kids these days... just don't respect their elders like
> they should ;-). I have seen more and more 'newish' devs speaking their
> minds like this without even knowing/asking the person. I guess respect
> and tactfulness isn't being taught anymore...
>
> And yes, Grant definitely knows the difference :-)

Maybe I do not understand the diffference between "I assume" and "I know", and
"I know" I meant the first, however, in that case, Grant, I do not know why
you're requesting this combine when you know about these "issues" already.
Don't get me wrong, I am (though, I was) just curious, and really surprised
how the hell ppl (telling to be coders) can even think about such merges. It
might - of course - *somehow* still be possible, but I just do not believe
in, as I posted earlier (by example).

And just like kintaco said, there're not only ppl outside that do know why
those archs are different, there're also ppl outside that even make use of
such things on *their* main arch (x86) and do not care (or did) about 64bit
compats, in fact, most do not know that this piece of could would lead into
semantic errors on such archs anyway.

As said, don't get me wrong, I'm neither new (depends on definition!) nor am I
"missing respect". I was just sharing some by-example snippets why this is a
bad idea, and I was just "assuming" (not "know") why I said what I said.

Regards,
Christian Parpart.

Ciaran McCreesh

unread,
Sep 4, 2005, 11:40:11 AM9/4/05
to
On Sun, 4 Sep 2005 11:08:58 +0200 Christian Parpart <tra...@gentoo.org>
wrote:

| Maybe I do not understand the diffference between "I assume" and "I
| know", and "I know" I meant the first, however, in that case, Grant,
| I do not know why you're requesting this combine when you know about
| these "issues" already.

Probably because he understands both the 32/64 issues and the portage
side of things far better than you do.

0 new messages