Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 30 Dec 1995 09:12:48 -0800
From:      David Greenman <davidg@Root.COM>
To:        Ollivier Robert <roberto@keltia.freenix.fr>
Cc:        peter@jhome.dialix.com (Peter Wemm), joerg@freefall.freebsd.org, cvs-bin@freefall.freebsd.org, CVS-committers@freefall.freebsd.org
Subject:   Re: cvs commit: src/bin/ps ps.1 
Message-ID:  <199512301712.JAA03238@corbin.Root.COM>
In-Reply-To: Your message of "Sat, 30 Dec 95 15:50:42 %2B0100." <199512301450.PAA16695@keltia.freenix.fr> 

next in thread | previous in thread | raw e-mail | index | archive | help
>It seems that Peter Wemm said:
>> Hmm. this was a suprise to me...  I thought procfs was optional, but it 
>> doesn't look like, since libkvm reads the /proc/<pid>/mem files.
>
>On the same subject, is it expected to all the "files" in /proc/<pid> to be
>of size 0 ? 
>
>total 0
>--w-------  1 root  staff  0 Dec 30 15:50 ctl
>----------  1 root  staff  0 Dec 30 15:50 fpregs
>----r-----  1 root  kmem   0 Dec 30 15:50 mem
>--w-------  1 root  staff  0 Dec 30 15:50 note
>--w-------  1 root  staff  0 Dec 30 15:50 notepg
>----------  1 root  staff  0 Dec 30 15:50 regs
>-r--r--r--  1 root  staff  0 Dec 30 15:50 status
>
>I'd expect mem to be the size of the binary in the VM system... 

   Yes, it's expected to be zero. "mem" is the process's virtual memory and
thus it is sparse. It would have to be nearly 4GB before the number would be
accurate. Our kernel allows seeking/reading the file even though it's beyond
the EOF. If we change the size to be non-zero, then ordinary things like grep
will read the contents...this can be BAD, especially when they are part of a
"find / | xargs grep foo". :-) It also prevents people from mmaping the file
contents, and this is desired for various reasons (which is the reason that
the rest of the files are 0 length). The main reason mmap of procfs files
is undesired is that they aren't real files and the data changes dynamically.
You don't want to cache that and you don't want to get a fault for _every_
access. There's no way to win, so we don't allow it.

-DG



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512301712.JAA03238>