From: William Lee Irwin III <wli@holomorphy.com>
To: Greg Ungerer <gerg@snapgear.com>
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>, Roger Luethi <rl@hellgate.ch>
Subject: Re: [1/1][PATCH] nproc v2: netlink access to /proc information
Date: Mon, 13 Sep 2004 23:23:07 -0700 [thread overview]
Message-ID: <20040914062307.GF9106@holomorphy.com> (raw)
In-Reply-To: <20040914061800.GD9106@holomorphy.com>
Greg, could you comment on this since there are some people having
trouble figuring out what's going on with VM-related /proc/ fields for
!CONFIG_MMU. Please forgive the top-posting, it made more sense to
quote the text below in this instance.
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).
On Mon, Sep 13, 2004 at 11:18:00PM -0700, William Lee Irwin III wrote:
> 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 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).
On Mon, Sep 13, 2004 at 11:18:00PM -0700, William Lee Irwin III wrote:
> 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.
next prev parent reply other threads:[~2004-09-14 6:23 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-08 18:40 [0/1][ANNOUNCE] " 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
2004-09-14 6:23 ` William Lee Irwin III [this message]
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=20040914062307.GF9106@holomorphy.com \
--to=wli@holomorphy.com \
--cc=akpm@osdl.org \
--cc=albert@users.sf.net \
--cc=gerg@snapgear.com \
--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
all inboxes | Powered by JetHome®