* [9fans] size on /proc files?
@ 2003-03-30 10:36 Aharon Robbins
2003-03-30 12:34 ` David Presotto
0 siblings, 1 reply; 5+ messages in thread
From: Aharon Robbins @ 2003-03-30 10:36 UTC (permalink / raw)
To: 9fans
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [9fans] size on /proc files?
2003-03-30 10:36 [9fans] size on /proc files? Aharon Robbins
@ 2003-03-30 12:34 ` David Presotto
2003-03-30 12:48 ` David Presotto
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: David Presotto @ 2003-03-30 12:34 UTC (permalink / raw)
To: 9fans
[-- 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [9fans] size on /proc files?
2003-03-30 12:34 ` David Presotto
@ 2003-03-30 12:48 ` David Presotto
2003-03-30 14:48 ` Russ Cox
2003-03-31 9:08 ` Aharon Robbins
2 siblings, 0 replies; 5+ messages in thread
From: David Presotto @ 2003-03-30 12:48 UTC (permalink / raw)
To: 9fans
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [9fans] size on /proc files?
2003-03-30 12:34 ` David Presotto
2003-03-30 12:48 ` David Presotto
@ 2003-03-30 14:48 ` Russ Cox
2003-03-31 9:08 ` Aharon Robbins
2 siblings, 0 replies; 5+ messages in thread
From: Russ Cox @ 2003-03-30 14:48 UTC (permalink / raw)
To: 9fans
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [9fans] size on /proc files?
2003-03-30 12:34 ` David Presotto
2003-03-30 12:48 ` David Presotto
2003-03-30 14:48 ` Russ Cox
@ 2003-03-31 9:08 ` Aharon Robbins
2 siblings, 0 replies; 5+ messages in thread
From: Aharon Robbins @ 2003-03-31 9:08 UTC (permalink / raw)
To: 9fans
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-03-31 9:08 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-30 10:36 [9fans] size on /proc files? Aharon Robbins
2003-03-30 12:34 ` David Presotto
2003-03-30 12:48 ` David Presotto
2003-03-30 14:48 ` Russ Cox
2003-03-31 9:08 ` Aharon Robbins
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).