[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGWvnykkDPs6n-uQTDVetCoRj5pV4i3YeT9FrHoJd0nAVf745Q@mail.gmail.com>
Date: Sun, 25 Jun 2017 10:56:14 -0400
From: David Edelsohn <dje.gcc@...il.com>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] powerpc64le: Add single instruction math functions
On Sun, Jun 25, 2017 at 10:28 AM, Rich Felker <dalias@...c.org> wrote:
> On Sat, Jun 24, 2017 at 11:24:59PM -0400, David Edelsohn wrote:
>> > Except those based on musl? I mean, we at Adélie haven't /shipped/
>> > anything PPC64 yet, but I have very good reasons for that (and will
>> > get to them later in this email).
>>
>> Because the PowerPC software ecosystem is based on and designed to
>> those assumptions. All of the JITs are based on that. All of the
>> optimized libraries are based on that. All of the hand-written
>> assembly code is based on that.
>>
>> Some test ABI and endianness separately, some don't. It definitely is
>> less well tested, if at all.
>>
>> You can do whatever you want, but it has been difficult enough fixing
>> all of the poor assumptions in the entire Open Source and proprietary
>> source ecosystem for the change to PPC64LE ELFv2. If you and Adelie
>> want to take on that challenge for PPC64BE ELFv2, great. The
>> OpenPower Foundation and its members are not going to fight that
>> battle.
>
> I see where you're coming from, but I don't see where it's
> significantly harder than fighting with and fixing software that
> doesn't work with musl due to gratuitous (or sometimes moderately
> reasonable) glibcisms. Having this type of ABI issue increases the
> number of such cases a bit, but I don't expect it to be a significant
> portion of the overall work.
>
>> > I apologise if my words seem strong, but I do not take this lightly.
>> > We have a number of users clamouring for us to save their older PPC64
>> > hardware from unmaintained AIX, unmaintained Debian, or in some cases
>> > ten-or-more year old fruity OSes. I obviously do not expect ABI
>> > compatibility with decades-old non-Linux Unixes. However, if there
>> > needs to be an ELFv1 port for a technical reason, I may have to
>> > investigate maintaining the port myself.
>>
>> As I wrote above, the entire external ecosystem makes the endianness /
>> ABI assumption. Golang assumes this. OpenJDK assumes this. ATLAS
>> BLAS and OpenBLAS assume this. GMP assumes this. PyPy assumes this.
>> Mono assumes this. libffi assumes this. Erlang probably assumes this.
>> FFMPEG, x264, libvpx assume this. MongoDB may assume this. NVIDIA
>> nvcc assumes this. Etc., etc., etc.
>
> Several of these are trivially fixed with --disable-asm or similar --
> at least gmp, ffmpeg, x264, and libvpx should fall in that category.
> Obviously it's desirable to get the asm working to improve
> performance, but it can be done incrementally. It also should be
> possible to heuristically test for this kind of thing by grepping for
> ppc64 asm function prologue in the sources.
>
> Only stuff that actually does codegen (compilers, jits, etc.) has a
> fundamental reason to be affected, and for the most part fixing it
> should just be a matter of fixing the conditionals that look for
> endianness to look for _CALL_ELF==2 where that's what they really
> meant to do.
>
>> It's not that the packages fundamentally cannot be fixed, but the
>> FLOSS ecosystem is much larger, richer, complex and more
>> interdependent. If one wants to create an embedded system, one can
>> exert control over the entire software ecosystem. For a
>> Linux-compatible system, one cannot.
>>
>> If you accept that some parts of the software ecosystem simply won't
>> build or function correctly for your system and configuration, or some
>> packages randomly will stop building or stop functioning correctly
>> after a package is updated, fine.
>
> These are already risks inherent in using a musl-based system with
> upstream packages that are developed on glibc and don't pay attention
> to portability issues. We have a very good history of the distros
> using musl making efforts to patch these kinds of things, send patchs
> upstream, and educate upstreams without attacking or patronizing them.
> Sometimes upstream regressions happen, but adequate testing should
> catch them.
Rich,
I am not arguing against big-endian PowerPC nor a powerpc64 BE ELFv2
port of musl nor building powerpc64 BE ELFv2 Linux. Mr. Wilcox asked
about the technical challenges and I replied.
The companies backing OpenPower have chosen a particular direction and
they are investing resources in that direction. The developers, most
of whom work for those companies and their partners, are working in
that direction. Most of the paid developers will not invest a lot of
time and effort in BE functionality and support. PowerPC already is a
small market, so further fragmentation isn't helpful. Without
corporate backing, the creation of an alternate Linux configuration
and ecosystem is a Herculean task.
Again, I am not and never was arguing against Mr. Wilcox's plans nor
against including powerpc64 BE ELFv2 support in musl libc. As I wrote
when I submitted the patch, I added the macro tests for completeness
and to allow future flexibility.
Thanks, David
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
