Re: bug#47615: [PATCH 0/9] Add 32-bit powerpc support

[Efraim Flashner <efraim@flashner.co.il>]

[-- Attachment #1: Type: text/plain, Size: 4096 bytes --]

On Thu, May 06, 2021 at 04:38:38PM +0200, Ludovic Courtès wrote:
> Hi Efraim,
> 
> Efraim Flashner <efraim@flashner.co.il> skribis:
> 
> > On Sat, Apr 17, 2021 at 06:04:02PM +0200, Ludovic Courtès wrote:
> 
> [...]
> 
> >>   3. OTOH, what will be the status of this architecture?  I don’t think
> >>      new 32-bit PPC hardware is being made (right?), so I guess we
> >>      probably won’t have substitutes for that architecture.  That means
> >>      it won’t be supported at the same level as other architectures and
> >>      may quickly suffer from bitrot.
> >
> > I don't know about new 32-bit powerpc hardware, I think it's only being
> > newly created for the embedded and networking space. As far as operating
> > systems with support¹ Adélie Linux is the only one I know that's
> > actually targeting the machines.
> >
> > I found that emulation on my desktop (Ryzen 3900XT, 24 threads) is
> > faster than building on native hardware (1 core, 1.5GB of RAM, original
> > 4200 RPM disk), edging it out on single threaded compiling and doing
> > great when it comes to using multiple cores and parallel builds.
> > Ignoring how to create an OS image if we just targeted, say, mesa and
> > maybe one or two other packages, we could have a core set which doesn't
> > change regularly and won't take up too much emulated build time but will
> > save days of compile time.
> 
> [...]
> 
> > The fear of bit-rot is real and I think we should mention in the manual
> > (when I actually write the section) that support is best-effort with
> > minimal substitutes.
> 
> I feel like “best-effort with minimal substitutes” is already more than
> I’d be willing to commit to as a maintainer.

I have also learned that 'best effort' is a grey area in other circles;
does it mean you'll move mountains and spare no expense (The Best
Effort!™) or that you'll give it a shot but make no promises. I
definitely meant the second.

> We just added POWER9, for which we have actual hardware, and even
> getting to this minimal state where we provide a binary tarball required
> quite some effort.
> 
> Doing the same with 32-bit PowerPC would require us to set up emulation;
> we wouldn’t even have real hardware.
> 
> All in all, my preference would be to take the patches but not mention
> PowerPC 32-bit support anywhere, or at least, not provide substitutes
> and binary installation tarball.  IOW, few people would know whether it
> actually works :-) but tinkerers could still play with it.
> 
> WDYT?
> 
> Ludo’.

How about changing the mips64el documentation to say that there is
minimal support for the two architectures, with no substitutes, and may
be fun for tinkerers with the hardware. Then we could also change the
check in the guix.m4 to add mips64el-linux as supported in case anyone
does actually want to play with it.

Current text:

@item mips64el-linux (deprecated)¬
little-endian 64-bit MIPS processors, specifically the Loongson series,
n32 ABI, and Linux-Libre kernel.  This configuration is no longer fully
supported; in particular, there is no ongoing work to ensure that this
architecture still works.  Should someone decide they wish to revive this
architecture then the code is still available.

Proposed text:

@item Alternative architectures
In addition to architectures which are actually supported there are a
few formally unsupported architectures which may be of interested to
tinkerers. Namely mips64el-linux, little-endian 64-bit MIPS processors,
specifically the Loongson series, n32 ABI, and powerpc-linux, big-endian
32-bit POWER processors, specifically the PowerPC 74xx series. There are
no installation tarballs, substitutes or promises that these
architectures are functional.

And then I'd move it lower than the powerpc64le-linux entry.


-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]