[9fans] size on /proc files?

[9fans] size on /proc files?

[Aharon Robbins]

Just out of curiousity, what does ls -l on special files in /proc report?
On linux, e.g., /proc/filesystems shows up as a regular file, but of size
zero.  Yet when you cat it you get information.

This behavior broke the current gawk, where I'd rewritten the get_a_record
routines; they had a check:

	if (S_ISREG(sbuf.st_mode) && total > sbuf.st_size)
		flag |= AT_EOF;

I had to change this to

	if (S_ISREG(sbuf.st_mode) && sbuf.st_size > 0
	    && total > sbuf.st_size) ....

I am annoyed at the Linux behavior, but understand that the contents
of these "files" can change dynamically, making the reporting of a size
for stat difficult or impossible.

So, I was just curious how Plan 9 handles it.

Thanks,

Arnold Robbins

Re: [9fans] size on /proc files?

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 173 bytes --]

We're equally stupid, though we could to a bit better.  The register
files and status files show the real lengths but the text and mem
file don't.  I'll see what I can do.

[-- Attachment #2: Type: message/rfc822, Size: 2193 bytes --]

From: Aharon Robbins <arnold@skeeve.com>
To: 9fans@cse.psu.edu
Subject: [9fans] size on /proc files?
Date: Sun, 30 Mar 2003 13:36:14 +0300
Message-ID: <200303301036.h2UAaEFZ031353@localhost.localdomain>

Just out of curiousity, what does ls -l on special files in /proc report?
On linux, e.g., /proc/filesystems shows up as a regular file, but of size
zero.  Yet when you cat it you get information.

This behavior broke the current gawk, where I'd rewritten the get_a_record
routines; they had a check:

	if (S_ISREG(sbuf.st_mode) && total > sbuf.st_size)
		flag |= AT_EOF;

I had to change this to

	if (S_ISREG(sbuf.st_mode) && sbuf.st_size > 0
	    && total > sbuf.st_size) ....

I am annoyed at the Linux behavior, but understand that the contents
of these "files" can change dynamically, making the reporting of a size
for stat difficult or impossible.

So, I was just curious how Plan 9 handles it.

Thanks,

Arnold Robbins

Re: [9fans] size on /proc files?

[David Presotto]

Thinking a bit more on it and looking at devproc.c and sysproc.c, the text
size is easy to get right, it's in the text segment.  The process is a
bit more problematic since the address space is sparse.  The text/data/bss are
at one end (right after an invalid page to catch null regs), the stack at the other,
and other segs anywhere in between.  The easy thing would be to say all procs are
0x7ffff000 bytes long.  That would help your get_a_record routine but wouldn't
really be very informative.  You'ld be better off reading the segment file to see what
is and isn't there than just checking a length of the mem file.

Re: [9fans] size on /proc files?

[Russ Cox]

It is worth pointing out that while we don't report
the sizes for variable-length files in /proc, we 
do report some of the fixed-length ones:

--rw-rw---- p 0 rsc rsc   0 Mar 27 00:17 /proc/1/args
--rw-r----- p 0 rsc rsc   0 Mar 27 00:17 /proc/1/ctl
--r--r--r-- p 0 rsc rsc   0 Mar 27 00:17 /proc/1/fd
--rw-r----- p 0 rsc rsc 108 Mar 27 00:17 /proc/1/fpregs
--r--r----- p 0 rsc rsc  76 Mar 27 00:17 /proc/1/kregs
--rw-r----- p 0 rsc rsc   0 Mar 27 00:17 /proc/1/mem
--rw-r----- p 0 rsc rsc   0 Mar 27 00:17 /proc/1/note
--rw-rw-r-- p 0 rsc rsc   0 Mar 27 00:17 /proc/1/noteid
--rw-r----- p 0 rsc rsc   0 Mar 27 00:17 /proc/1/notepg
--r--r--r-- p 0 rsc rsc   0 Mar 27 00:17 /proc/1/ns
--r--r----- p 0 rsc rsc   0 Mar 27 00:17 /proc/1/proc
--r--r----- p 0 rsc rsc   0 Mar 27 00:17 /proc/1/profile
--rw-r----- p 0 rsc rsc  76 Mar 27 00:17 /proc/1/regs
--r--r--r-- p 0 rsc rsc   0 Mar 27 00:17 /proc/1/segment
--r--r--r-- p 0 rsc rsc 176 Mar 27 00:17 /proc/1/status
--rw-r----- p 0 rsc rsc   0 Mar 27 00:17 /proc/1/text
--r--r----- p 0 rsc rsc   0 Mar 27 00:17 /proc/1/wait

We should probably report the sizes of args, noteid, 
and notepg too.

Also, I think you're really asking about devices in
general rather than /proc in particular.  (It's only an
artifact of Linux that /dev has half moved into /proc.)

We do get a lot of the important ones right:

--rw-rw-r-- c   0 rsc    rsc          24 Mar 27 00:17 /dev/bintime
--r--r--r-- c   0 rsc    rsc          72 Mar 27 00:17 /dev/cputime
--rw-rw-r-- c   0 rsc    rsc          48 Mar 27 00:17 /dev/hostdomain
--rw-rw-rw- L   0 rsc    rsc           1 Mar 27 00:17 /dev/lpt1dlr
--r--r--r-- L   0 rsc    rsc           5 Mar 27 00:17 /dev/lpt1psr
--r--r--r-- c   0 rsc    rsc          12 Mar 27 00:17 /dev/pgrpid
--r--r--r-- c   0 rsc    rsc          12 Mar 27 00:17 /dev/pid
--r--r--r-- c   0 rsc    rsc          12 Mar 27 00:17 /dev/ppid
--rw-rw-r-- c   0 rsc    rsc          78 Mar 27 00:17 /dev/time
--r--r--r-- $   0 rsc    rsc         128 Mar 27 00:17 /dev/pci/0.0.0raw
--r--r--r-- $   0 rsc    rsc         128 Mar 27 00:17 /dev/pci/0.15.0raw
--r--r--r-- $   0 rsc    rsc         128 Mar 27 00:17 /dev/pci/0.16.0raw
--r--r--r-- $   0 rsc    rsc         128 Mar 27 00:17 /dev/pci/0.7.0raw
--r--r--r-- $   0 rsc    rsc         128 Mar 27 00:17 /dev/pci/0.7.1raw
--r--r--r-- $   0 rsc    rsc         128 Mar 27 00:17 /dev/pci/0.7.3raw

though about as many are wrong.

And of course, the disks are always right:

--rw-rw---- f   0 rsc    rsc     1474560 Mar 27 00:17 /dev/fd0disk
--rw-rw---- f   0 rsc    rsc     1474560 Mar 27 00:17 /dev/fd1disk
--rw-r----- S   0 rsc    rsc     2097152 Mar 27 00:17 /dev/sdC0/9fat
--rw-r----- S   0 rsc    rsc 48004669440 Mar 27 00:17 /dev/sdC0/data
--rw-r----- S   0 rsc    rsc 20971528704 Mar 27 00:17 /dev/sdC0/dos
--rw-r----- S   0 rsc    rsc   960700416 Mar 27 00:17 /dev/sdC0/fossil
--rw-r----- S   0 rsc    rsc  6121381888 Mar 27 00:17 /dev/sdC0/fs
--rw-r----- S   0 rsc    rsc  6123479040 Mar 27 00:17 /dev/sdC0/plan9
--rw-r----- S   0 rsc    rsc 20909629440 Mar 27 00:17 /dev/sdC0/plan9.1
--rw-r----- S   0 rsc    rsc 16727702528 Mar 27 00:17 /dev/sdC0/v.arenas
--rw-r----- S   0 rsc    rsc   805306368 Mar 27 00:17 /dev/sdC0/v.index0
--rw-r----- S   0 rsc    rsc   805306368 Mar 27 00:17 /dev/sdC0/v.index1
--rw-r----- S   0 rsc    rsc   805306368 Mar 27 00:17 /dev/sdC0/v.index2
--rw-r----- S   0 rsc    rsc   805306368 Mar 27 00:17 /dev/sdC0/v.index3

I'm curious: if you use devfs on Linux, do you get sizes for
some of the devices when you stat them?  Seems like it
would be easy in that framework.

Russ

Re: [9fans] size on /proc files?

[Aharon Robbins]

David,

I don't know that I advocate actually changing any OS code.  I was just
curious what Plan 9 does.  It came up because someone did

	gawk '/devfs/ { print }' /proc/filesystems

and that failed.  My changed code would now work as-is under Plan 9, so I'll
leave it at that.  I may even remove the test, and just rely exclusively
on a zero return from read() to indicate EOF.  (rob would probably tell me
that's what I should have done in the first place. I think I even tried
that and it didn't work, which indicates that I need to rethink the code
some more.)

Thanks,

Arnold

P.S., just out of curiousity, can someone feeling charitable try to configure
and compile gawk under Plan 9? I'm curious if it would work, at least under
the APE. ftp://ftp.gnu.org/gnu/gawk/gawk-3.1.2.tar.gz. `configure --disable-nls'
is probably better than plain configure. If it fails, don't feel obligated
to submit patches or sink a lot of time into it. Thanks.

In article <091f807138892efebadcbbde9ac80bd7@plan9.bell-labs.com>,
David Presotto <9fans@cse.psu.edu> wrote:
>-=-=-=-=-=-
>
>We're equally stupid, though we could to a bit better.  The register
>files and status files show the real lengths but the text and mem
>file don't.  I'll see what I can do.
>-=-=-=-=-=-
>
>Just out of curiousity, what does ls -l on special files in /proc report?
>On linux, e.g., /proc/filesystems shows up as a regular file, but of size
>zero.  Yet when you cat it you get information.
>
>This behavior broke the current gawk, where I'd rewritten the get_a_record
>routines; they had a check:
>
>	if (S_ISREG(sbuf.st_mode) && total > sbuf.st_size)
>		flag |= AT_EOF;
>
>I had to change this to
>
>	if (S_ISREG(sbuf.st_mode) && sbuf.st_size > 0
>	    && total > sbuf.st_size) ....
>
>I am annoyed at the Linux behavior, but understand that the contents
>of these "files" can change dynamically, making the reporting of a size
>for stat difficult or impossible.
>
>So, I was just curious how Plan 9 handles it.
>
>Thanks,
>
>Arnold Robbins
>-=-=-=-=-=-


-- 
Aharon (Arnold) Robbins --- Pioneer Consulting Ltd.	arnold@skeeve.com
P.O. Box 354		Home Phone: +972  8 979-0381	Fax: +1 928 569 9018
Nof Ayalon		Cell Phone: +972 51  297-545
D.N. Shimshon 99785	ISRAEL