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: <3C9EB8F6.247C7C3B@zip.com.au>; from akpm@zip.com.au on Sun, Mar 24, 2002 at 09:43:18PM -0800
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:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-23 22:07 Does e2fsprogs-1.26 work on mips? H . J . Lu
2002-03-24 0:21 ` Andrew Morton
[not found] ` <20020323221627.A10953@lucon.org>
[not found] ` <3C9D7A42.B106C62D@zip.com.au>
2002-03-24 9:28 ` 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-26 10:51 ` Paul Mackerras
2002-03-25 17:17 ` H . J . Lu
-- strict thread matches above, loose matches on Subject: below --
2002-03-25 10:52 Peter Hartley
2002-03-25 17:07 ` H . J . Lu
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.