On Friday, May 16, 2014, 8:07:47 PM, Dennis Gilmore wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > On Fri, 16 May 2014 18:58:14 -0400 > Al Dunsmuir <al.dunsmuir@xxxxxxxxxxxx> wrote: >> 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. > cross compilation is the only way to bring up a new architecture >> 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? > The builds today happen in a 32 bit chroot on 64 bit hardware. the > chroot is made from scratch every build just as all the other arches > are. > Dennis That's very good news. It means physical ppc32 hosting was not used up to now on ppc32, and a resurrected ppc32 should be able to play by the same rules. _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
