This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RESEND] [PATCH] PPC64: First in the series of patches implementing


Joseph Myers <joseph@codesourcery.com> writes:

> On Thu, 28 Feb 2019, Tulio Magno Quites Machado Filho wrote:
>
>> 1. Guarantee the new code does not export neither a new ABI nor a new API.
>
> Right now it does export an ABI (meaning both the library symbols, and the 
> declarations in bits/math-vector.h that are expected to be interpreted by 
> a future compiler as meaning, in accordance with the ABI document that 
> needs to be written, that those library symbols are available - 
> bits/math-vector.h being installed regardless of whether the library is 
> built).

Agreed.  That has to be modified in the next patch submission.

>> 2. A description on how to enable the code in order to test it without compiler
>>    support.  A public branch/repository is ideal.
>
> Sure, a branch is appropriate; the issues with lack of compiler support 
> are issues for having the support on master.  Then, maybe a wiki page that 
> points to the glibc branch, the GCC branch (once available), the current 
> work on the ABI, etc., so people can find all the relevant pieces.

Agreed.

> When a feature crosses multiple toolchain components (or involves the 
> kernel as well as glibc, etc.), close cooperation between the people 
> developing the features in those different components can be necessary - 
> which means patch submissions for each component should include detailed 
> information about the status of the work for the other components (and 
> pointers to patches or such a wiki page, or CC the person working on the 
> other components and ask them to describe the status, etc.).

Agreed.

>> 3. Review the patch in order to guarantee it does match the community
>>    standards.
>
> This process is already ongoing.  (But if the series ends up including 
> sincos it will be especially important to look closely at compiler 
> interactions there, given the issues that arose on x86_64 - the addition 
> of sincos will need to come with a careful explanation of what the ABI is, 
> which may or may not be the same as that used for x86_64, of why that's 
> the right ABI for POWER, and of how the header declarations result in that 
> ABI being used.)

Ack.

-- 
Tulio Magno


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]