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: [PATCH 1/5] Consolidate sem_open implementations


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?

> ---
>  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.


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