On Friday, May 16, 2014, 4:41:51 PM, Josh Boyer wrote: > On Fri, May 16, 2014 at 3:12 PM, Al Dunsmuir <al.dunsmuir@xxxxxxxxxxxx> wrote: >> On Friday, May 16, 2014, 2:50:15 PM, Josh Boyer wrote: >>> On Fri, May 16, 2014 at 2:37 PM, Al Dunsmuir <al.dunsmuir@xxxxxxxxxxxx> wrote: >>>> On Friday, May 16, 2014, 12:22:26 PM, Josh Boyer wrote: >> I know someone who has sparc, alpha hardware. I'm not sure if they >> have an ia64 box taking up space in a closet somewhere. > Great. I know someone that has the hardware too. We still removed > support for both in the kernel spec because it was entirely moribund. That is reasonable. > Hardware availability is often secondary to sustained effort from > people that have that hardware. History shows that people seem less > interested in keeping it running when they have to do the work or go > it alone in doing the work. Human nature. We'll hope there is a different outcome. >>>> Making it so that ppc32 does not get built by default is one thing, >> >>> Actually, it's a very very big thing. Those wishing to keep it alive >>> now need to come up with their own build hardware and build enviroment >>> setup. This is by far the largest hurdle, and if it isn't done >>> quickly the ppc32 secondary-secondary (thirdary?) arch will quickly >>> fall behind and into disrepair. >> Some folks have volunteered to host the builds, and provide build >> hardware. We'll see how that works out. If we do have to build outside >> the Fedora systems, there are going to be security considerations. > Outside build systems are probably going to be a requirement here. > That is how ARM started, so it's not unreasonable. I doubt you're > going to get Fedora Infrastructure to host any ppc32 hardware in the > colo due to both space and configuration issues (they only take rack > machines). We need to see what can be done to make sure we can stay "Fedora" under those circumstances. Being forced to be a Fedora-like remix would be a shame if that is the only issue. >>>> but removing the ability to build ppc32 at all seems excessive, and >>>> certainly premature given the current situation. >> >>> Which is why I sent it as a patch instead of simply committed it. >>> Discussion is requested. At a minimum though, I really would like to >>> drop the -smp flavor because it was of very limited use even when ppc >>> was a primary arch and it adds the most complication to the spec. >> >> Thanks for clarifying that. >> >> The problem with dropping smp is that I and other have smp hardware >> that we would like to use. That is also likely the hardware that > Yes, I've seen that. I'm willing to hold off on the removal for a bit > to see how quickly your effort gets off the ground. I won't wait > forever though. Entirely reasonable. > To be clear, whatever is built is entirely supported by the team doing > the ppc32 work. Any bugs filed in Fedora bugzilla will get assigned > to the contact person. That's pretty well the way it is with ARM even now, whether they like it or not. There is likely to be a rare occasion when ppc32 discovers an issue that also affects other builds. Reproducing on on X86, X86_64, or ppc64 should allow the problem to be addressed by the regular developers. Worst case, providing a remote login seems to be the standard approach. >> would best be used for builds, should "build native" and lack of a >> ppc32 cross compiler & binutils mean we can's use a ppc64 build host. > Cross-compiling is not allowed in Fedora anyway. Which is really > unfortunate because it is actually a very useful thing to do in > situations just like this. That is the rule for release builds, but like ARM (and ARM64) sometimes you have to use cross-compilation during bring up. Unlike ARM, ppc64 does support user processes running in ppc32 mode (via multi-arch). Do the current (up to today) ppc32 builds run on ppc32 hardware, or do they run on ppc64 machines via multi-arch? If there is ppc32-only hardware, why can't we continue to use it? _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
