From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-53935-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 16008 invoked by alias); 30 Oct 2014 02:55:03 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 15610 invoked by uid 89); 30 Oct 2014 02:54:59 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2
X-HELO: mx1.redhat.com
Message-ID: <5451A85B.5020709@redhat.com>
Date: Thu, 30 Oct 2014 02:55:00 -0000
From: "Carlos O'Donell" <carlos@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: Darren Hart <dvhart@infradead.org>
CC: Rich Felker <dalias@libc.org>, Roland McGrath <roland@hack.frob.com>,
        Torvald Riegel <triegel@redhat.com>,
        GLIBC Devel <libc-alpha@sourceware.org>,
        Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: Add futex wrapper to glibc?
References: <1410881785.4967.292.camel@triegel.csb> <20140917194100.23B722C26C5@topped-with-meat.com> <1410983178.27838.27.camel@triegel.csb> <20140917195918.6F06C2C3974@topped-with-meat.com> <20140917231708.GC23797@brightrain.aerifal.cx> <544953F7.1020607@redhat.com> <20141030015915.GF14609@vmdeb7>
In-Reply-To: <20141030015915.GF14609@vmdeb7>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SW-Source: 2014-10/txt/msg00733.txt.bz2

On 10/29/2014 09:59 PM, Darren Hart wrote:
> I wonder though... can we not wrap FUTEX_REQUEUE? It's fundamentally broken.
> FUTEX_CMP_REQUEUE should *always* be used instead. The glibc wrapper is one way
> to encourage developers to do the right thing (don't expose the bad op in the
> header).

We can do whatever you want, but you should document it as broken in the
linux kernel man pages if it is not already. Then when we add the wrapper
we'll make sure it's not there.

The WIP consensus is that deprecated kernel syscalls or features will
not be part of wrappers.

Cheers,
Carlos.