This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] sh: Use generic lowlevellock-futex.h.
- From: Torvald Riegel <triegel at redhat dot com>
- To: Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 18 Dec 2014 11:33:52 +0100
- Subject: Re: [PATCH] sh: Use generic lowlevellock-futex.h.
- Authentication-results: sourceware.org; auth=none
- References: <1418856067 dot 20194 dot 7 dot camel at triegel dot csb> <20141218 dot 092804 dot 179811418 dot kkojima at rr dot iij4u dot or dot jp>
On Thu, 2014-12-18 at 09:28 +0900, Kaz Kojima wrote:
> Torvald Riegel <triegel@redhat.com> wrote:
> > This completely untested patch removes the custom definitions of futex
> > functions in sh lowlevellock.h, using the generic lowlevellock-futex.h
> > instead. This is part of the clean-up efforts regarding the
> > glibc-internal futex API (e.g., adding proper error checking).
> >
> > This also removes the sh4 lowlevellock.h, which just requires more
> > padding for the syscalls; the same requirement is made by sh4 sysdep.h,
> > so INTERNAL_SYSCALL used in the generic lowlevellock-futex.h will honor
> > this too.
> >
> > This keeps the custom asm for the lock fast paths because I don't know
> > whether the generic C implementation would be fine. If it would be
> > (e.g., test with sh's lowlevellock.h removed), then removing the custom
> > asm altogether would be even better.
> >
> > Is this OK for sh? If not, do you have an alternative suggestion for
> > how to use the generic futex interfaces?
>
> The patch is OK.
OK, thanks.
> I definitely agree with your view about the custom asm. Switch to
> the generic C implementation would be simply fine and the way to go.
Does that mean I can simply commit a patch that removes the custom
lowlevellock.h, or do you want to test this further before this is
committed?