Re: [PATCH v3 2/6] nptl: Add POSIX-proposed sem_clockwait

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 25/06/2019 18:39, Florian Weimer wrote:
> * Mike Crowe:
> 
>> On Tuesday 25 June 2019 at 20:06:53 +0200, Florian Weimer wrote:
>>> * Mike Crowe:
>>>
>>>> On Wednesday 05 June 2019 at 18:07:18 -0300, Adhemerval Zanella wrote:
>>>>> On 27/05/2019 17:03, Mike Crowe wrote:
>>>>>> Add:
>>>>>>
>>>>>>  int sem_clockwait (sem_t *sem, clockid_t clock, const struct timespec *abstime)
>>>>>>
>>>>>> which behaves just like sem_timedwait, but measures abstime against the
>>>>>> specified clock. Currently supports CLOCK_REALTIME and CLOCK_MONOTONIC and
>>>>>> sets errno == EINVAL if any other clock is specified.
>>>>>
>>>>> For non-POSIX definition we will need to first export it as a GNU extension
>>>>> with a possible non-reserved name and later, when it is included on the 
>>>>> standard, to add an alias to the expected name.  
>>>>>
>>>>> The usual naming scheme is to append the _np suffix (non-portable) on 
>>>>> implementation, similar to recent posix_spawn file action extensions.
>>>>> In this case it would be sem_clockwait_np.
>>>
>>>> I thought we went through this before[1] and agreed that the _np suffix wasn't
>>>> necessary in this case. However, I couldn't find a reply to Florian
>>>> agreeing to that.
>>>
>>> Upon second thought, I agree with Adhemerval here.  We should use a
>>> function with the _np suffix, otherwise we'll be in a world of pain if
>>> something else is standardized.
>>
>> Well, the plan is to standardise this[1] and The Austin Group are the ones
>> who decided on the names, but there needs to be an implementation before
>> that can happen. Presumably that implementation can have _np suffixes in
>> the short term though.
>>
>> I shall apply some sed to the patch series and repost.
> 
> Sorry, I see that we don't use _np for the other functions.
> I'm confused now. 8-(
> 
> Adhemerval, is there value in keeping this consistent?  Have these
> functions progressed to different stages in the POSIX process?

My understanding of Austin proposal [1] (Mike can correct me) is naming is
settled and Android will also probably follow the same naming scheme. However, 
since Austin Group does not really propose newer interfaces, they
required a actual implementation to move forward.

Joseph also added sometime ago on IRC that we should add the symbols with 
the expected naming, but keep in mind there might be future incompatibilities 
requiring symbol versioning.

[1] http://austingroupbugs.net/view.php?id=1216