From: William Lee Irwin III <wli@holomorphy.com>
To: Roger Luethi <rl@hellgate.ch>
Cc: Albert Cahalan <albert@users.sf.net>,
Andrew Morton OSDL <akpm@osdl.org>,
linux-kernel mailing list <linux-kernel@vger.kernel.org>,
Paul Jackson <pj@sgi.com>
Subject: Re: [1/1][PATCH] nproc v2: netlink access to /proc information
Date: Mon, 13 Sep 2004 23:18:00 -0700 [thread overview]
Message-ID: <20040914061800.GD9106@holomorphy.com> (raw)
In-Reply-To: <20040914055946.GA20929@k3.hellgate.ch>
On Sat, 11 Sep 2004 18:25:56 -0400, Albert Cahalan wrote:
>> No. First of all, I think they can be offered. Until proven
>> otherwise, I'll assume that the !CONFIG_MMU case is buggy.
On Tue, Sep 14, 2004 at 07:59:46AM +0200, Roger Luethi wrote:
> I agree with you that those specific fields should be offered for
> !CONFIG_MMU. However, if for some reason they cannot carry a value
> that fits the field description, they should not be offered at all. The
> ambiguity of having 0 mean either "0" or "this field is not available"
> is bad. Trying to read a specific field _can_ fail, and applications
> had better handle that case (it's still trivial compared to having to
> parse different /proc file layouts depending on the configuration).
Apart from doing something it's supposed to for !CONFIG_MMU and using
the internal kernel accounting I set up for the CONFIG_MMU=y case I'm
not very concerned about this. I have a vague notion there should
probably be some consistency with the /proc/ precedent but am not
particularly tied to it. We should probably ask Greg Ungerer (the
maintainer of the external MMU-less patches) about what he prefers
since it's likely we can't anticipate all of the !CONFIG_MMU concerns.
On Sat, 11 Sep 2004 18:25:56 -0400, Albert Cahalan wrote:
>> mean that fewer apps can run on !CONFIG_MMU boxes. It's
>> same problem as "All the world's a VAX". It's better that
>> the apps work; an author working on a Pentium 4 Xeon is
>> likely to write code that relies on the fields and might
>> not really understand what "no MMU" is all about.
On Tue, Sep 14, 2004 at 07:59:46AM +0200, Roger Luethi wrote:
> The presumed wrong assumptions underlying broken tools of the future
> are not a good base for designing a new interface. My interest is in
> making it easy to write correct applications (or in fixing broken apps
> that won't work, say, on !CONFIG_MMU systems).
I don't really know what the approach to app compatibility used by
userspace for !CONFIG_MMU is; I'll refer you to Greg Ungerer as my
knowledge of the CONFIG_MMU usage models and/or whatever userspace
is used in tandem with it outside the VM's internals is rather scant.
-- wli
next prev parent reply other threads:[~2004-09-14 6:20 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-08 18:40 [0/1][ANNOUNCE] nproc v2: netlink access to /proc information Roger Luethi
2004-09-08 18:41 ` [1/1][PATCH] " Roger Luethi
2004-09-09 0:35 ` William Lee Irwin III
2004-09-09 0:43 ` William Lee Irwin III
2004-09-09 1:15 ` William Lee Irwin III
2004-09-09 1:17 ` [1/2] rediff nproc v2 vs. 2.6.9-rc1-mm4 William Lee Irwin III
2004-09-09 1:21 ` [2/2] handle CONFIG_MMU=n and use new vm stats for CONFIG_MMU=y William Lee Irwin III
2004-09-09 1:22 ` William Lee Irwin III
2004-09-09 1:26 ` [3/2] round up text memory to the nearest page in fs/proc/task_mmu.c William Lee Irwin III
2004-09-09 18:43 ` [1/1][PATCH] nproc v2: netlink access to /proc information Roger Luethi
2004-09-09 18:49 ` William Lee Irwin III
2004-09-09 19:00 ` William Lee Irwin III
2004-09-09 19:02 ` [4/2] consolidate __task_mem() and __task_mem_cheap() William Lee Irwin III
2004-09-09 19:07 ` Roger Luethi
2004-09-09 19:15 ` [5/2] fix nommu VSZ reporting in consolidated task_mem() William Lee Irwin III
2004-09-09 19:11 ` [1/1][PATCH] nproc v2: netlink access to /proc information Roger Luethi
2004-09-09 19:23 ` William Lee Irwin III
2004-09-09 21:19 ` Roger Luethi
2004-09-10 15:30 ` Roger Luethi
2004-09-11 22:25 ` Albert Cahalan
2004-09-12 4:58 ` William Lee Irwin III
2004-09-14 5:59 ` Roger Luethi
2004-09-14 6:18 ` William Lee Irwin III [this message]
2004-09-14 6:23 ` William Lee Irwin III
2004-09-14 7:47 ` Greg Ungerer
2004-09-14 8:27 ` Roger Luethi
2004-09-09 11:53 ` Stephen Smalley
2004-09-09 17:22 ` William Lee Irwin III
2004-09-09 17:53 ` Roger Luethi
2004-09-09 20:01 ` Stephen Smalley
2004-09-09 20:48 ` Chris Wright
2004-09-10 12:11 ` Stephen Smalley
2004-09-09 20:55 ` Roger Luethi
2004-09-09 21:05 ` Chris Wright
2004-09-09 21:25 ` Roger Luethi
2004-09-11 22:36 ` Albert Cahalan
2004-09-12 5:00 ` William Lee Irwin III
2004-09-14 6:44 ` Roger Luethi
2004-09-14 7:10 ` William Lee Irwin III
2004-09-14 7:55 ` Roger Luethi
2004-09-14 8:01 ` William Lee Irwin III
2004-09-14 9:27 ` Roger Luethi
2004-09-14 15:37 ` William Lee Irwin III
2004-09-14 16:01 ` Roger Luethi
2004-09-14 16:37 ` William Lee Irwin III
2004-09-14 17:15 ` Roger Luethi
2004-09-14 17:43 ` William Lee Irwin III
2004-09-14 18:45 ` Roger Luethi
2004-09-14 19:07 ` William Lee Irwin III
2004-09-14 19:31 ` Roger Luethi
2004-09-14 19:36 ` William Lee Irwin III
2004-09-14 19:50 ` Roger Luethi
2004-09-15 11:44 ` Roger Luethi
2004-09-15 20:02 ` Roger Luethi
2004-09-15 20:20 ` William Lee Irwin III
2004-09-15 20:33 ` Roger Luethi
2004-09-15 20:44 ` Roger Luethi
2004-09-14 18:37 ` Chris Wright
2004-09-14 18:55 ` Roger Luethi
2004-09-14 19:05 ` Chris Wright
2004-09-14 21:12 ` Roger Luethi
2004-09-09 20:44 ` Chris Wright
2004-09-16 21:43 ` nproc: So? Roger Luethi
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=20040914061800.GD9106@holomorphy.com \
--to=wli@holomorphy.com \
--cc=akpm@osdl.org \
--cc=albert@users.sf.net \
--cc=linux-kernel@vger.kernel.org \
--cc=pj@sgi.com \
--cc=rl@hellgate.ch \
/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