From: Theodore Tso <tytso@mit.edu>
To: Andrew Morton <akpm@zip.com.au>
Cc: Theodore Tso <tytso@mit.edu>, "H . J . Lu" <hjl@lucon.org>,
linux-mips@oss.sgi.com,
linux kernel <linux-kernel@vger.kernel.org>,
GNU C Library <libc-alpha@sources.redhat.com>
Subject: Re: Does e2fsprogs-1.26 work on mips?
Date: Tue, 26 Mar 2002 01:54:40 -0500 [thread overview]
Message-ID: <20020326015440.A12162@thunk.org> (raw)
In-Reply-To: <20020323140728.A4306@lucon.org> <3C9D1C1D.E30B9B4B@zip.com.au> <20020323221627.A10953@lucon.org> <3C9D7A42.B106C62D@zip.com.au> <20020324012819.A13155@lucon.org> <20020325003159.A2340@thunk.org> <3C9EB8F6.247C7C3B@zip.com.au>
On Sun, Mar 24, 2002 at 09:43:18PM -0800, Andrew Morton wrote:
> Theodore Tso wrote:
> >
> > And just to be clear ---- although in the past I've been really
> > annoyed when glibc has made what I've considered to be arbitrary
> > changes which have screwed ABI, compile-time, or link-time
> > compatibility, and have spoken out against it --- in this particular
> > case, I consider the fault to be purely the fault of the kernel
> > developers, so there's no need having the glibc folks get all
> > defensive....
>
> So... Does the kernel need fixing? If so, what would you
> recommend?
1) Created a new syscall for the unsinged setrlimit, not just for
getrlimit. This should have been done from the very beginning, IMHO.
2) If the old value of RLIM_INFINITY is passed to the old setrlimit,
translate it to the new value of RLIM_INFINITY. (This would not have
been strictly necessary of glibc wasn't playing RLIM_INIFITY capping
games; as it turns out, if you pass the "new" version of RLIM_INIFITY
to an "old" 2.2 kernel, the right thing happens. So there really is
no need for glibc to cap the limit of RLIM_INFINITY to the old value.)
3) RLIMIT_FILESIZE should not apply to block devices!!!
- Ted
next prev parent reply other threads:[~2002-03-26 6:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20020323140728.A4306@lucon.org>
[not found] ` <3C9D1C1D.E30B9B4B@zip.com.au>
[not found] ` <20020323221627.A10953@lucon.org>
[not found] ` <3C9D7A42.B106C62D@zip.com.au>
2002-03-24 9:28 ` Does e2fsprogs-1.26 work on mips? H . J . Lu
2002-03-25 5:31 ` Theodore Tso
2002-03-25 5:43 ` Andrew Morton
2002-03-26 6:54 ` Theodore Tso [this message]
2002-03-26 10:51 ` Paul Mackerras
2002-03-25 17:17 ` H . J . Lu
2002-03-25 10:52 Peter Hartley
2002-03-25 17:07 ` H . J . Lu
-- strict thread matches above, loose matches on Subject: below --
2002-03-25 19:00 Peter Hartley
2002-03-25 19:11 ` H . J . Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020326015440.A12162@thunk.org \
--to=tytso@mit.edu \
--cc=akpm@zip.com.au \
--cc=hjl@lucon.org \
--cc=libc-alpha@sources.redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox