[gentoo-dev] Gentoo i486 support

[gentoo-dev] Gentoo i486 support

[Ben Kohler]

Hi guys,

For some time now, we've been shipping broken i486 stage3s that do not 
run on pre-i686 hardware [1].  Due to a change in catalyst [2], we no 
longer set CXXFLAGS in the default make.conf, so the x86 profiles' (imho 
wrong/broken) defaults [3] kick in.

I'd like to get this fixed, and I see 3 possible solutions, listed in 
order of my own preference:

1) Adjust x86 profile defaults to drop the problematic -march=i686. 
This would be more in line with amd64 profiles (et al), which set no 
-march value so it can run on any hardware for this arch.

2) Patch catalyst to start setting CXXFLAGS again.  Rather than roll 
back to exactly CXXFLAGS="${CFLAGS}" again, it's been suggested that we 
start setting COMMON_FLAGS, and CFLAGS="${COMMON_FLAGS}" 
CXXFLAGS=${COMMON_FLAGS}" etc.  I prepared such a patch a while back 
[4], which seems to work but may need a bit of updating.

3) Drop i486 support.  We're only pretending to have support now, we 
could officially stop building these broken stages completely.

Personally I think #1 is the most technically correct and least amount 
of work.  The only result will be slightly less optimized builds for 
people who choose not to customize *FLAGS at all in make.conf.  But this 
is correct behavior.  What we have now is akin to setting -march=core2 
on amd64 stage3 and saying "oops it doesn't work on early 64bit AMD 
cpus, but oh well most people have newer and will appreciate the 
optimization".

Thoughts?

-Ben

[1] https://bugs.gentoo.org/654080
[2] 
https://gitweb.gentoo.org/proj/catalyst.git/commit/?id=b409bd9bb4b50f69a555e4e148057ade86a7ed16
[3] 
https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/arch/x86/make.defaults
[4] https://bugs.gentoo.org/575446#c4

Re: [gentoo-dev] Gentoo i486 support

[Rich Freeman]

On Wed, Aug 22, 2018 at 8:26 AM Ben Kohler <bkohler@gentoo.org> wrote:
>
> 1) Adjust x86 profile defaults to drop the problematic -march=i686.
> This would be more in line with amd64 profiles (et al), which set no
> -march value so it can run on any hardware for this arch.
>

My knee-jerk reaction was that this is a bad idea, but after a bit of
thought there are some arguments in favor of this:

First, the argument against: i386 is VERY old.  Most distros moved
their defaults to i686 because it had significant improvements, and
i686 was still mainstream but i386 was ancient.  In contrast with
amd64 the entire architecture is fairly new and the baseline doesn't
suffer from many of the issues i386 suffers compared to i686.  This is
a really short synopsis - if you go to any distro list archive you can
find long passionate arguments from ~10 years ago that elaborated on
this.  In that sense, going back to i386 is turning back the clock.

HOWEVER, I think there is an argument for i386 that wasn't so valid
back then.  x86 in general is starting to look a bit like i386.  What
are the main use cases for it in this day and age?  I don't use x86,
so I'm not the best person to answer that.  However, I'd broadly split
it into two categories (mostly by tautology):

1.  Museum hardware.  People have systems that are running simply
BECAUSE they are old, not because they are cost-effective/etc.  I'm
not sure I'd even lump used hardware into this category any longer, as
I'm sure there are plenty of i686+ used PCs at rock-bottom prices
already out there, and maintaining pre-Y2K hardware is going to be
fairly painful.  For this use case i386 as the baseline makes a LOT of
sense.

2.  Non-museum hardware.  People have x86 hardware because it is the
most cost-effective solution for a task, and not merely because it is
old.  IMO for this use case i686 makes a lot more sense as a baseline.
However, I'm honestly not sure in this day and age what these use
cases even are, unless it is something you can buy for $10 at a flea
market.  Even if you're talking about a container running one
application that only needs 500kB of RAM, is there really that much
benefit to not building it for amd64?

The other argument for i386 would be that in Gentoo nobody is stuck
with the defaults.  So, a default that works more widely as an entry
point makes a lot of sense, since anybody can set CFLAGs and do an
emerge -e world to get the benefits.  Then again, if we're talking
about older but not ancient hardware that is still quite a bit of
build time.

IMO the best thing here would be for people to actually RUN x86 to
chime in.  I've been amd64-only on Gentoo since not long after I
started using Gentoo (and that was back when mplayer barely could be
made to work on amd64).  Once upon a time I could have bought the
pointer size argument around RAM use, but if that were really a big
concern I think more people would be running x32.

Is there a large population that actually runs x86 on modern hardware,
or is ancient hardware a significant use case?

-- 
Rich

Re: [gentoo-dev] Gentoo i486 support

[Mart Raudsepp]

[-- Attachment #1: Type: text/plain, Size: 1420 bytes --]

Ühel kenal päeval, K, 22.08.2018 kell 09:08, kirjutas Rich Freeman:
> On Wed, Aug 22, 2018 at 8:26 AM Ben Kohler <bkohler@gentoo.org>
> wrote:
> > 
> > 1) Adjust x86 profile defaults to drop the problematic -march=i686.
> > This would be more in line with amd64 profiles (et al), which set
> > no
> > -march value so it can run on any hardware for this arch.
> > 
> 
> My knee-jerk reaction was that this is a bad idea, but after a bit of
> thought there are some arguments in favor of this:
> 
> First, the argument against: i386 is VERY old.

The topic is i486, not i386.
i486 stages allows to more easily start up gentoo on i486 and i586
hardware, possibly also for some i686.
E.g. if I'd ever get around to working on Geode graphics again, I would
want a i486 or i586 stage to start with, as CMOV on the Geode is a
performance penalty, not benefit, plus glibc i486 or i586 glibc
intrinsics were faster than i686 ones as well. This includes a million
or so OLPC XO-1's out there, not that they'd ever install Gentoo
though, but just an example. I think some old VIAs are another?
i686 builds sometimes wrongly make use of NOPL instruction as well,
though hopefully that was fixed for good in binutils.

Anyways, my point is that we are talking about being able to boot i486
and i586 here, not i386.
Personally I can manage my potential own future needs without weekly
stages.


Mart

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] Gentoo i486 support

[Peter Stuge]

Rich Freeman wrote:
> Is there a large population that actually runs x86 on modern
> hardware, or is ancient hardware a significant use case?

There are current products with pre-686 instruction sets.

Companies such as DM&P still produce 586-class SoCs for embedded and
industrial. These[1][2] are current products.

And Intel Quark[3] is another one.

I prefer option number 1 as suggested in the initial mail.


//Peter

[1] https://en.wikipedia.org/wiki/Vortex86
[2] http://www.vortex86.com/?p=264
[3] https://en.wikipedia.org/wiki/Intel_Quark

Re: [gentoo-dev] Gentoo i486 support

[R0b0t1]

On Wed, Aug 22, 2018 at 8:08 AM, Rich Freeman <rich0@gentoo.org> wrote:
> 1.  Museum hardware.  People have systems that are running simply
> BECAUSE they are old, not because they are cost-effective/etc.  I'm
> not sure I'd even lump used hardware into this category any longer, as
> I'm sure there are plenty of i686+ used PCs at rock-bottom prices
> already out there, and maintaining pre-Y2K hardware is going to be
> fairly painful.  For this use case i386 as the baseline makes a LOT of
> sense.
>
> 2.  Non-museum hardware.  People have x86 hardware because it is the
> most cost-effective solution for a task, and not merely because it is
> old.  IMO for this use case i686 makes a lot more sense as a baseline.
> However, I'm honestly not sure in this day and age what these use
> cases even are, unless it is something you can buy for $10 at a flea
> market.  Even if you're talking about a container running one
> application that only needs 500kB of RAM, is there really that much
> benefit to not building it for amd64?
>

I don't want to get very offtopic, but:

Even newer embedded i586 and i686 hardware isn't cost effective
considering power consumption. When considering power it often does
not even make sense to run donated hardware ~5 years old.

I don't think this should be used to completely drop support for older
platforms but it is probably the best argument to use to convince
people to get rid of their old hardware.


> The other argument for i386 would be that in Gentoo nobody is stuck
> with the defaults.  So, a default that works more widely as an entry
> point makes a lot of sense, since anybody can set CFLAGs and do an
> emerge -e world to get the benefits.  Then again, if we're talking
> about older but not ancient hardware that is still quite a bit of
> build time.
>

This is definitely in the spirit of Gentoo, but I think the most
concrete reason to support older platforms is they are demonstrably
more secure and people may be using them for that reason.

Cheers,
    R0b0t1

Re: [gentoo-dev] Gentoo i486 support

[Rich Freeman]

On Wed, Aug 22, 2018 at 4:27 PM R0b0t1 <r030t1@gmail.com> wrote:
>
> Even newer embedded i586 and i686 hardware isn't cost effective
> considering power consumption. When considering power it often does
> not even make sense to run donated hardware ~5 years old.
>

I was referring to running the x86 arch on hardware that is
otherwise-capable of running the amd64 arch.  I'm not really sure how
important that would be, but I wanted to at least consider the
possibility.

In any case, this is becoming moot it seems.

-- 
Rich

Re: [gentoo-dev] Gentoo i486 support

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2747 bytes --]

Hi!

On Wed, 22 Aug 2018 09:08:06 -0400 Rich Freeman wrote:
> On Wed, Aug 22, 2018 at 8:26 AM Ben Kohler <bkohler@gentoo.org> wrote:
> >
> > 1) Adjust x86 profile defaults to drop the problematic -march=i686.
> > This would be more in line with amd64 profiles (et al), which set no
> > -march value so it can run on any hardware for this arch.
> >
> 
> My knee-jerk reaction was that this is a bad idea, but after a bit of
> thought there are some arguments in favor of this:
> 
> First, the argument against: i386 is VERY old.  Most distros moved
> their defaults to i686 because it had significant improvements, and
> i686 was still mainstream but i386 was ancient.  In contrast with
> amd64 the entire architecture is fairly new and the baseline doesn't
> suffer from many of the issues i386 suffers compared to i686.  This is
> a really short synopsis - if you go to any distro list archive you can
> find long passionate arguments from ~10 years ago that elaborated on
> this.  In that sense, going back to i386 is turning back the clock.
> 
> HOWEVER, I think there is an argument for i386 that wasn't so valid
> back then.  x86 in general is starting to look a bit like i386.  What
> are the main use cases for it in this day and age?  I don't use x86,
> so I'm not the best person to answer that.  However, I'd broadly split
> it into two categories (mostly by tautology):
> 
> 1.  Museum hardware.  People have systems that are running simply
> BECAUSE they are old, not because they are cost-effective/etc.  I'm
> not sure I'd even lump used hardware into this category any longer, as
> I'm sure there are plenty of i686+ used PCs at rock-bottom prices
> already out there, and maintaining pre-Y2K hardware is going to be
> fairly painful.  For this use case i386 as the baseline makes a LOT of
> sense.
> 
> 2.  Non-museum hardware.  People have x86 hardware because it is the
> most cost-effective solution for a task, and not merely because it is
> old.  IMO for this use case i686 makes a lot more sense as a baseline.
> However, I'm honestly not sure in this day and age what these use
> cases even are, unless it is something you can buy for $10 at a flea
> market.  Even if you're talking about a container running one
> application that only needs 500kB of RAM, is there really that much
> benefit to not building it for amd64?

As active x86 hardware user I can add:

3. Security. CPUs without speculative execution and L3 cache are
much more secure by design. Thanks to the virtues of Gentoo
(highest possible code optimization and ability to USE light
versions of applications) such hardware (e.g. 32bit Atoms) is still
usable quite fine.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Gentoo i486 support

[James Le Cuirot]

On Wed, 22 Aug 2018 07:26:24 -0500
Ben Kohler <bkohler@gentoo.org> wrote:

> For some time now, we've been shipping broken i486 stage3s that do
> not run on pre-i686 hardware [1].  Due to a change in catalyst [2],
> we no longer set CXXFLAGS in the default make.conf, so the x86
> profiles' (imho wrong/broken) defaults [3] kick in.
> 
> I'd like to get this fixed, and I see 3 possible solutions, listed in 
> order of my own preference:
> 
> 1) Adjust x86 profile defaults to drop the problematic -march=i686. 
> This would be more in line with amd64 profiles (et al), which set no 
> -march value so it can run on any hardware for this arch.
> 
> 2) Patch catalyst to start setting CXXFLAGS again.  Rather than roll 
> back to exactly CXXFLAGS="${CFLAGS}" again, it's been suggested that
> we start setting COMMON_FLAGS, and CFLAGS="${COMMON_FLAGS}" 
> CXXFLAGS=${COMMON_FLAGS}" etc.  I prepared such a patch a while back 
> [4], which seems to work but may need a bit of updating.

You do get similar issues with other variables. I recently noticed that
CHOST_arm is sometimes used (by LLVM? can't remember…) instead of just
CHOST. Because we were only setting CHOST_arm="${CHOST}" in the base
arch/arm profile, it was still carrying the original value of
arm-unknown-linux-gnu regardless of what subprofiles or the user had
set. I've explicitly set it in the subprofiles now but this still isn't
great.

> 3) Drop i486 support.  We're only pretending to have support now, we 
> could officially stop building these broken stages completely.
> 
> Personally I think #1 is the most technically correct and least
> amount of work.  The only result will be slightly less optimized
> builds for people who choose not to customize *FLAGS at all in
> make.conf.  But this is correct behavior.  What we have now is akin
> to setting -march=core2 on amd64 stage3 and saying "oops it doesn't
> work on early 64bit AMD cpus, but oh well most people have newer and
> will appreciate the optimization".

I do get nostalgic about this old hardware but I wouldn't expect anyone
to use it now. A year or so ago, I tried to run the latest Linux kernel
in 16MB RAM. I had to use zram just to squeeze out an extra 2MB and
even then, it was at the absolute limit. Bear in mind this was a very
stripped down LEDE installation. 486s can have more RAM but why bother?
The oldest PC I ran Gentoo on in remotely recent times was a Pentium
120 MMX and that was only because the form factor was unusually small.
I would maybe still try it on my Amiga 1200 for laughs but that has the
added novelty factor of not being a PC. On that basis, I would suggest
dropping the stages but that doesn't mean we shouldn't fix things
anyway. Apart from just making it correct, it is possible to install
Gentoo without a stage tarball. I created our bogsucker ppc64le dev box
by cross-compiling @system with the help of my cross-boss tool.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Re: [gentoo-dev] Gentoo i486 support

[Mike Gilbert]

On Wed, Aug 22, 2018 at 8:26 AM Ben Kohler <bkohler@gentoo.org> wrote:
>
> Hi guys,
>
> For some time now, we've been shipping broken i486 stage3s that do not
> run on pre-i686 hardware [1].  Due to a change in catalyst [2], we no
> longer set CXXFLAGS in the default make.conf, so the x86 profiles' (imho
> wrong/broken) defaults [3] kick in.
>
> I'd like to get this fixed, and I see 3 possible solutions, listed in
> order of my own preference:
>
> 1) Adjust x86 profile defaults to drop the problematic -march=i686.
> This would be more in line with amd64 profiles (et al), which set no
> -march value so it can run on any hardware for this arch.

Based on a quick test, running i686-pc-linuc-gnu-gcc without passing
-march seems to be equivalent to passing "-mtune=generic -march=i686".
So, you'll get code that will only run on i686, but has "generic"
tuning (whatever that means).

I don't think that will make a noticeable difference on user systems.
Most Gentoo people probably override this to some more specific CPU
model via CFLAGS in make.conf anyway.

So +1 from me on removing -march=i686 from the x86 arch profile.

Re: [gentoo-dev] Gentoo i486 support

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 233 bytes --]

On 2018-08-22 16:30, Mike Gilbert wrote:
> So +1 from me on removing -march=i686 from the x86 arch profile.

+1


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] Gentoo i486 support

[Matt Turner]

On Wed, Aug 22, 2018 at 5:26 AM Ben Kohler <bkohler@gentoo.org> wrote:
> 2) Patch catalyst to start setting CXXFLAGS again.  Rather than roll
> back to exactly CXXFLAGS="${CFLAGS}" again, it's been suggested that we
> start setting COMMON_FLAGS, and CFLAGS="${COMMON_FLAGS}"
> CXXFLAGS=${COMMON_FLAGS}" etc.  I prepared such a patch a while back
> [4], which seems to work but may need a bit of updating.
[snip]
> [2]
> https://gitweb.gentoo.org/proj/catalyst.git/commit/?id=b409bd9bb4b50f69a555e4e148057ade86a7ed16

I don't think that was intentional, was it?

That commit looks like it's supposed to just be a plain refactor (It's
titled "stagebase.py: Refactor the *FLAGS handling code in
chroot_setup()" after all) so it shouldn't have changed behavior. I'm
guessing the commit is just broken. It doesn't even look like the
commit message was finished when it was pushed.

I think you should do whatever is required to fix catalyst brokenness.

Re: [gentoo-dev] Gentoo i486 support

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 1641 bytes --]

On 22/08/18 20:20, Matt Turner wrote:
> On Wed, Aug 22, 2018 at 5:26 AM Ben Kohler <bkohler@gentoo.org> wrote:
>> 2) Patch catalyst to start setting CXXFLAGS again.  Rather than roll
>> back to exactly CXXFLAGS="${CFLAGS}" again, it's been suggested that we
>> start setting COMMON_FLAGS, and CFLAGS="${COMMON_FLAGS}"
>> CXXFLAGS=${COMMON_FLAGS}" etc.  I prepared such a patch a while back
>> [4], which seems to work but may need a bit of updating.
> [snip]
>> [2]
>> https://gitweb.gentoo.org/proj/catalyst.git/commit/?id=b409bd9bb4b50f69a555e4e148057ade86a7ed16
> I don't think that was intentional, was it?
>
> That commit looks like it's supposed to just be a plain refactor (It's
> titled "stagebase.py: Refactor the *FLAGS handling code in
> chroot_setup()" after all) so it shouldn't have changed behavior. I'm
> guessing the commit is just broken. It doesn't even look like the
> commit message was finished when it was pushed.
>
> I think you should do whatever is required to fix catalyst brokenness.
>
Discussions on IRC in -releng demonstrate that this change resulted in
the CXXFLAGS variable *disappearing* from the stage3 make.conf. I
consider this a regressoin. I haven't personally looked as to how this
happened (although I'm familiar with the code from ARM profile changes),
but I think that also needs fixing. All my workstations descend from the
time when both CFLAGS *and* CXXFLAGS were set in make.conf and I hadn't
noticed this until today; however, this is a secondary issue to the one
that Ben has highlighted, which is a rather unhelpful fall-back
situation for x86 users ..

MJE


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Gentoo i486 support

[Richard Yao]

[-- Attachment #1.1: Type: text/plain, Size: 1918 bytes --]

On 08/22/2018 08:26 AM, Ben Kohler wrote:
> Hi guys,
> 
> For some time now, we've been shipping broken i486 stage3s that do not
> run on pre-i686 hardware [1].  Due to a change in catalyst [2], we no
> longer set CXXFLAGS in the default make.conf, so the x86 profiles' (imho
> wrong/broken) defaults [3] kick in.
> 
> I'd like to get this fixed, and I see 3 possible solutions, listed in
> order of my own preference:
> 
> 1) Adjust x86 profile defaults to drop the problematic -march=i686. This
> would be more in line with amd64 profiles (et al), which set no -march
> value so it can run on any hardware for this arch.
> 
> 2) Patch catalyst to start setting CXXFLAGS again.  Rather than roll
> back to exactly CXXFLAGS="${CFLAGS}" again, it's been suggested that we
> start setting COMMON_FLAGS, and CFLAGS="${COMMON_FLAGS}"
> CXXFLAGS=${COMMON_FLAGS}" etc.  I prepared such a patch a while back
> [4], which seems to work but may need a bit of updating.
> 
> 3) Drop i486 support.  We're only pretending to have support now, we
> could officially stop building these broken stages completely.
> 
> Personally I think #1 is the most technically correct and least amount
> of work.  The only result will be slightly less optimized builds for
> people who choose not to customize *FLAGS at all in make.conf.  But this
> is correct behavior.  What we have now is akin to setting -march=core2
> on amd64 stage3 and saying "oops it doesn't work on early 64bit AMD
> cpus, but oh well most people have newer and will appreciate the
> optimization".
Agreed.
> 
> Thoughts?
> 
> -Ben
> 
> [1] https://bugs.gentoo.org/654080
> [2]
> https://gitweb.gentoo.org/proj/catalyst.git/commit/?id=b409bd9bb4b50f69a555e4e148057ade86a7ed16
> 
> [3]
> https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/arch/x86/make.defaults
> 
> [4] https://bugs.gentoo.org/575446#c4
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Gentoo i486 support

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

On Wed, 22 Aug 2018 07:26:24 -0500
Ben Kohler <bkohler@gentoo.org> wrote:

> Thoughts?

Is there a good reason we can't have a legacy profile for this?

Or perhaps, a new (exp) arch entirely dedicated to legacy x86?

The latter would be ideal for ensuring everything we *claim* works on
i486 does indeed work there, and making it blatantly obvious what does
and doesn't work on i486.

And both strategies make it possible to restrict USE graphs to subsets
that can only work on i486.

The benefit of a new profile for x86 is it would assume everything
currently x86 works on i486, and then exceptions can be shot on a
case-by-case basis.

But that's also the downside, you start with a huge set and play
whack-a-mole with it, when ideally, you want to start with a *minimal*
working subset and build it out ( and this is where the second option
is better )

The arch-approach would also lend itself to compile-time switching in
individual packages too.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Gentoo i486 support

[Mike Gilbert]

On Fri, Aug 24, 2018 at 9:19 AM Kent Fredric <kentnl@gentoo.org> wrote:
>
> On Wed, 22 Aug 2018 07:26:24 -0500
> Ben Kohler <bkohler@gentoo.org> wrote:
>
> > Thoughts?
>
> Is there a good reason we can't have a legacy profile for this?
>
> Or perhaps, a new (exp) arch entirely dedicated to legacy x86?

Sounds like a lot of work for something that will be used by very few people.

Re: [gentoo-dev] Gentoo i486 support

[Rich Freeman]

On Fri, Aug 24, 2018 at 9:57 AM Mike Gilbert <floppym@gentoo.org> wrote:
>
> On Fri, Aug 24, 2018 at 9:19 AM Kent Fredric <kentnl@gentoo.org> wrote:
> >
> > On Wed, 22 Aug 2018 07:26:24 -0500
> > Ben Kohler <bkohler@gentoo.org> wrote:
> >
> > > Thoughts?
> >
> > Is there a good reason we can't have a legacy profile for this?
> >
> > Or perhaps, a new (exp) arch entirely dedicated to legacy x86?
>
> Sounds like a lot of work for something that will be used by very few people.
>

I think an exp arch is also overkill.  How many packages simply can't
be built for i486?  I think a profile+masking makes a lot more sense
than an entire new level of QA that touches every ebuild in the tree
because there might be a few packages that don't work on 25 year old
hardware.

-- 
Rich

Re: [gentoo-dev] Gentoo i486 support

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1934 bytes --]

On Fri, 24 Aug 2018 10:13:42 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> I think an exp arch is also overkill.  How many packages simply can't
> be built for i486?  I think a profile+masking makes a lot more sense
> than an entire new level of QA that touches every ebuild in the tree
> because there might be a few packages that don't work on 25 year old
> hardware.

In response to other conversations on #gentoo-x86, I think neither are
needed any more.

All that's needed to target this set is as follows:

1. Focus on the problem in terms of CPU instruction feature sets and
   memory limitations.

2. Make sure packages that don't work on i586 natively due to lack of
   instructions, and require adjustment, utilize CPU_FLAGS_X86 to
   expose this issue, ( eg: sse, mmx, cmov )

3. Make the CPU_FLAGS_X86 generator tool emits the ideal values when
   run locally on a given processor. 

4. For people targeting minimal should-at-least-work-on-i586/i486
   binary images, setting CPU_FLAGS_X86="-*" should be recommended.

5. For people targeting physically ancient platforms with binary media,
   it might be pertinent to standardize on some sort of USE flag to
   indicate to applicable packages to optimize for
   runtime-memory-constrained environments.


Or something along those lines. This should avoid all the downsides
of new-arches/new profiles, while still allowing ebuilds to introspect
and customize themselves as needed.

Additionally, the features not being bound to a profile means they can
be mixed and matched across profiles, so a memory-constrained
environment targeting i686/mips/arm can use the same controls.

And users who have, for example, CPUs' *with* the cmov instruction, but
an inferior/slow implementation, can opt-out of using that instruction.

And then using these tools we can throw minimal-flag-sets and
minimal-memory at stage builds.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]