lkml.org 
[lkml]   [2000]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Format of /proc/meminfo
I'd rather see a new /proc/memoryinfo with a lot of thought given to the
current and future structure of it than adding kludges into what already
exists.

Userland utils need to be more tolerant of "junk" and not rely on static
content locations.

-d

Dan Kegel wrote:

> Rik van Riel wrote:
> > > The only thing it can be a problem for an alternate VM if there
> > > would be user<->kernel API differences realted to the very
> > > internal of the memory management so if possible I'd like if
> > > that could be avoided.
> >
> > Sure, lets get rid of /proc/meminfo ;)
> >
> > But serious, if /proc/meminfo isn't there to give information
> > about the internal memory use of the system, why do we have
> > it? I don't see /proc/meminfo doing anything else than that...
>
> Andrea is worried about userland utilities getting confused
> because of differences in /proc/meminfo for various VM systems.
> Maybe it would be enough to put the entries that are
> VM-version specific after the generic ones, and preface them
> with the name of the VM system, e.g.

--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."


begin:vcard
n:Ford;David
x-mozilla-html:TRUE
org:<img src="http://www.kalifornia.com/images/paradise.jpg">
adr:;;;;;;
version:2.1
email;internet:david@kalifornia.com
title:Blue Labs Developer
x-mozilla-cpt:;28256
fn:David Ford
end:vcard
\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.068 / U:2.980 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site