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&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
Ü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