[PATCH 1/5] Consolidate sem_open implementations

Adhemerval Zanella adhemerval.zanella@linaro.org
Wed Sep 14 21:39:00 GMT 2016



On 05/09/2016 14:21, Torvald Riegel wrote:
> On Mon, 2016-08-22 at 11:27 -0300, Adhemerval Zanella wrote:
>> Current sparc32 sem_open and default one only differ on:
>>
>>   1. Default one contains a 'futex_supports_pshared' check.
>>   2. sem.newsem.pad is initialized to zero.
>>
>> This patch removes sparc32 and sparc32v9 sem_open arch specific
>> implementation and instead set sparc32 to use nptl default one.
>> Using 1. is fine since it should always evaluate 0 for Linux
>> (an optimized away by the compiler). Adding 2. to default
>> implementation should be ok since 'pad' field is used mainly
>> on sparc32 code.
>>
>> I checked on i686 and checked a sparc32v9 build.
>>
>> 	* nptl/sem_open.c (sem_open): Init pad value to 0.
>> 	* sysdeps/sparc/sparc32/sem_open.c: Remove file.
>> 	* sysdeps/sparc/sparc32/sparcv9/sem_open.c: Likewise.
> 
> Can you do something similar for sem_init please?

I will send a consolidation patch to sem_init.

> 
>> ---
>>  nptl/sem_open.c                          |   1 +
>>  sysdeps/sparc/sparc32/sem_open.c         | 300 -------------------------------
>>  sysdeps/sparc/sparc32/sparcv9/sem_open.c |   1 -
>>  4 files changed, 7 insertions(+), 301 deletions(-)
>>  delete mode 100644 sysdeps/sparc/sparc32/sem_open.c
>>  delete mode 100644 sysdeps/sparc/sparc32/sparcv9/sem_open.c
>>
>> diff --git a/nptl/sem_open.c b/nptl/sem_open.c
>> index 911b1f3..974cff9 100644
>> --- a/nptl/sem_open.c
>> +++ b/nptl/sem_open.c
>> @@ -207,6 +207,7 @@ sem_open (const char *name, int oflag, ...)
>>        sem.newsem.data = value;
>>  #else
>>        sem.newsem.value = value << SEM_VALUE_SHIFT;
>> +      sem.newsem.pad = 0;
>>        sem.newsem.nwaiters = 0;
>>  #endif
>>        /* This always is a shared semaphore.  */
> 
> I think we should add a comment there, pointing to the use of .pad as a
> mutex on pre-v9 sparc (same in sem_init when you consolidate this too).
> 
> Otherwise, this is OK.
> 

I will add a comment.



More information about the Libc-alpha mailing list