linux-mips
[Top] [All Lists]

Re: prlimit64: inconsistencies between kernel and userland

To: "Joseph S. Myers" <joseph@codesourcery.com>
Subject: Re: prlimit64: inconsistencies between kernel and userland
From: Rich Felker <dalias@aerifal.cx>
Date: Tue, 5 Nov 2013 17:39:53 -0500
Cc: David Daney <ddaney.cavm@gmail.com>, "Pinski, Andrew" <Andrew.Pinski@caviumnetworks.com>, Andreas Barth <aba@ayous.org>, David Miller <davem@davemloft.net>, aurelien@aurel32.net, linux-mips@linux-mips.org, libc-alpha@sourceware.org
In-reply-to: <Pine.LNX.4.64.1311052234420.30260@digraph.polyomino.org.uk>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20130628133835.GA21839@hall.aurel32.net> <20131104213756.GD18700@hall.aurel32.net> <20131104.194519.1657797548878784116.davem@davemloft.net> <Pine.LNX.4.64.1311050058580.9883@digraph.polyomino.org.uk> <20131105012203.GA24286@brightrain.aerifal.cx> <20131105085859.GE28240@mails.so.argh.org> <20131105183732.GB24286@brightrain.aerifal.cx> <52793C50.9030300@gmail.com> <Pine.LNX.4.64.1311052234420.30260@digraph.polyomino.org.uk>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, Nov 05, 2013 at 10:36:24PM +0000, Joseph S. Myers wrote:
> On Tue, 5 Nov 2013, David Daney wrote:
> 
> > Why can't the default version of the functions in question be fixed so that
> > they do the right thing?  That way you wouldn't have to rebuild old 
> > binaries.
> > 
> > Do we really need new function versions at all?
> 
> If we change RLIM64_INFINITY to match the kernel, then the right thing for 
> at least getrlimit64 depends on whether it's an old or new binary (for old 
> binaries it should return the old value of RLIM64_INFINITY and for new 
> ones it should return the new value).

BTW, what happens on a distro where -dev packages are separate and the
user compiles with old headers (not having upgraded the dev package)
but new libc.so? :-)

Rich

<Prev in Thread] Current Thread [Next in Thread>