On Thursday, August 31, 2017, 4:41:59 PM, Dan HorĂ¡k wrote:
On Thu, 31 Aug 2017 11:29:42 +0200
Florian Weimer <fweimer(a)redhat.com> wrote:
> I would like to tweak glibc so that it only builds one POWER
620/970
> libc for ppc64, and not multiple libcs with POWER6/POWER7/POWER8
> optimizations.
>
> This does not affect ppc64le in any way.
>
> The reason for this change is that the ppc64 builders are awfully slow
> as of late, and the multiple builds (four times currently) currently
> make ppc64 the slowest architecture to build by quite a margin.
>
> Any comments?
I think the reason for keeping lower bound as powerpc 970 is Apple
G5
as the last desktop class hw, with Talos II as the next viable desktop
solution coming I would even vote for having power8 as the base line
for ppc64 for some next Fedora version. Even when new developments are
done in the ppc64le flavour, ppc64 has it's value in for example easier
debugging big endian related issues. Until then ppc970 + power8
variants would be good enough (IMO).
Dan,
A couple of years ago I posted about my intent to help correct the the
G5 boot situation.
I saw that you were working on and off with another gent who was
working on some boot changes on GitHub, so that has been some
progress.
Aside from the obvious Anaconda and blivet changes, there need to be a
number of changes to improve support for Mac APM-format disks in
parted, pyparted, gparted, libblockdev, (et al). I came up with a
prototype which Brian C. Lane thought were good (including marking the
APM disk map partition as R/O to prevent a user accidently trashing
the disk). The parted primary maintainer (Phillip Susi) rejected them
because he insisted that the APM disk map partition be hidden, not
just R/O. A full restart is required, but my available free time
evaporated around that time.
Since then I've been busy with home renovations (total basement redo
for home office) that has taken the last year, and real work
(including porting nearly 700 RPMs to AIX this year.
I've been doing my AIX work on my own P4+ (7028-6C4 4X - CHRP) box.
I've picked up a P5 (9113-550) that I've not had time to seriously use
yet. My intent is to also get both working with Fedora PPC64 BE
release. Not really relevant to current Fedora, I've got a couple of
7046-B50 (32-bit CHRP) that I'm using for some AIX, plus intend to try
out NetBSD/ofppc.
I plan to finish the bulk of the AIX RPM work in November, and then to
restart the boot related work. Once I get up to speed and that is
solved, there seems to be some PREP partition (and GRUB CHRP) related
issue that also never seem to get any love, as most new hardware uses
PowerVM. I can work on those to the extent that my hardware allows me
to reproduce.
The G5, P4+ and P5 boxes are too outdated for RHEL/CentOS (currently
P6+) but represent the kind of hardware that a hobbyist can pick up
for a reasonable price. The Apple and IBM boxes tend to be very
heavily constructed (literally - 100LB+ for the R4+/P5) and if they
have made it this far (no capacitor issues) tend to soldier on
forever. It seems to me that folks using Fedora ppc64 tend to be
either on (b)leading edge hardware (P8 and now P9) or outdated
hardware. Anything in between tends to be RHEL/CentOS.
The price of newer systems like Talos II present a high barrier for
entry for personal use. The crowd-sourcing failed for this exact
reason. It would be fine for commercial use (where one can write off
the expense) but that tends to go RHEL/CentOS or be used LE only.
For big-endian platforms as a hobbyist, one is basically constrained to
vintage Apple/IBM for real hardware, or zSeries emulation on Hercules
(on x86).
It would be really helpful to keep the PPC BE port running for this
old hardware (absent restrictions in areas like go, rust and java) as
it's an interesting and different place than generic commodity PCs.
For these reason, I'm clearly in favour retaining the P8+ and 970
variants if the number of variations has to be reduced.
Al