lkml.org 
[lkml]   [1998]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: size of files in /proc
Date
From
In article <19980519102836.46981@fangorn.cs.monash.edu.au>,
Kevin Lentin <kevinl@cs.monash.edu.au> writes:
> On Sat, May 16, 1998 at 11:00:28AM -0400, Mike A. Harris wrote:
>> >
>> > Well, /proc/kcore already reports its actual size...
>>
>> And it isn't about to change at runtime either. That is the size
>> of installed memory. I've yet to see a single person
>> successfully insert or remove a SIMM/DIMM while a machine was
>> running. If they did, and it was successful, the linux code will
>> update the filesize. ;o)
>
> And even if you could resize memory, kcore could update it's size. The
> reason kcore shows its size is that the size is known. And it's also
> relevant! For most of the text files in /proc, you'd have to actually call
> the 'read' function to determine the size each time a readdir was done.
> Sounds like a very wasteful pursuit to me.
>
> I think that any /proc file whose size can be determined without generating
> its contents, might as well report it. But generating contents to determine
> size seems silly. And that's the only way you'll do it.
>

But even then I'd like /proc to report the unknown sizes as 1, not 0.
Because I like to be able to export /proc over NFS, and NFS doesn't even
bother to read the file if the size is 0.

A(nother) possibility is to cache the size from last time the file contents got
generated. For most files that should be in the right ballpark.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.116 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site