Re: [gentoo-dev] Gentoo i486 support
Hi! On Wed, 22 Aug 2018 09:08:06 -0400 Rich Freeman wrote: > On Wed, Aug 22, 2018 at 8:26 AM Ben Kohler 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 pgpcE7BQXwWmm.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo i486 support
On Fri, 24 Aug 2018 10:13:42 -0400 Rich Freeman 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. pgpbea3p7AHzh.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo i486 support
On Fri, Aug 24, 2018 at 9:57 AM Mike Gilbert wrote: > > On Fri, Aug 24, 2018 at 9:19 AM Kent Fredric wrote: > > > > On Wed, 22 Aug 2018 07:26:24 -0500 > > Ben Kohler 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
On Fri, Aug 24, 2018 at 9:19 AM Kent Fredric wrote: > > On Wed, 22 Aug 2018 07:26:24 -0500 > Ben Kohler 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
On Wed, 22 Aug 2018 07:26:24 -0500 Ben Kohler 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. pgpsM5mloWBRq.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo i486 support
On Wed, Aug 22, 2018 at 4:27 PM R0b0t1 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
On Wed, Aug 22, 2018 at 8:08 AM, Rich Freeman 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
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
>
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo i486 support
On 22/08/18 20:20, Matt Turner wrote:
> On Wed, Aug 22, 2018 at 5:26 AM Ben Kohler 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
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo i486 support
On Wed, Aug 22, 2018 at 5:26 AM Ben Kohler 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
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo i486 support
On Wed, Aug 22, 2018 at 8: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. 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
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 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
Ü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 > 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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo i486 support
On Wed, 22 Aug 2018 07:26:24 -0500
Ben Kohler 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
On Wed, Aug 22, 2018 at 8:26 AM Ben Kohler 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
[gentoo-dev] Gentoo i486 support
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
