From: Greg Ungerer <gerg@snapgear.com>
To: William Lee Irwin III <wli@holomorphy.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: Tue, 14 Sep 2004 17:47:52 +1000 [thread overview]
Message-ID: <4146A228.3080705@snapgear.com> (raw)
In-Reply-To: <20040914062307.GF9106@holomorphy.com>
Hi William, Roger,
William Lee Irwin III wrote:
> 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.
Yeah, the !CONFIG_MMU code behind this is probably a little stale.
The thinking has mostly been to keep things as much the same as
possible, even if the fields didn't have a sensible meaning in
non-mmu space.
> 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).
In at least one case this is true now, as you mention for the
VmXxx fields. But looking at these now I think we could actually
implement most of them in a sensible way for the no-mmu case.
Size, Exe, Lib, Stk, etc all apply with their conventional
meanings.
> 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).
Reality for non-mmu targets is that most apps just won't be fixed
for them, so we try real hard to make the world look like it is
just like any other linux architecture.
I think !CONFIG_MMU case can be cleaned up to make it almost identical
to the CONFIG_MMU case, and reporting sensible values for just about
all fields.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg@snapgear.com
SnapGear -- a CyberGuard Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
next prev parent reply other threads:[~2004-09-14 7:49 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
2004-09-14 6:23 ` William Lee Irwin III
2004-09-14 7:47 ` Greg Ungerer [this message]
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=4146A228.3080705@snapgear.com \
--to=gerg@snapgear.com \
--cc=akpm@osdl.org \
--cc=albert@users.sf.net \
--cc=linux-kernel@vger.kernel.org \
--cc=pj@sgi.com \
--cc=rl@hellgate.ch \
--cc=wli@holomorphy.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