/dev/proc

[Stephen J. Friedl]

In article <2840 at mybest6.UUCP>, paddock at mybest6.UUCP (Steve Paddock) writes:
> Would someone explain what the /proc filesystem is?  I infer from 
> Friedl's posting that it is on the 3B15 3.1 release.  Is it in 
> 3.2.1 for the 600?  3.2?  

     I started a lot of this /proc discussion, and I've done
enough investigation that I can probably speak to this.  Note
that most of this is the results of my own blind hacking, so
the authoritative tone should not be taken too seriously.

I'm told that the original reference for /proc is:

        %T Processes as Files
        %A T.J. Killian
        %J Proc. EUUG Autumn Conference
        %P 38-45
        %D Sep 1984

     Basically, the /proc filesystem is a mechanism for mapping
the process table into the filesystem, and it was invented by Tom
Killian at AT&T research.  Some of you may recall a mention in
the old docs for ptrace(2) saying "A much better interface should
be possible with ioctls()" -- this is it.  I've been told that
this version of /proc is different and considerably more powerful
than the research version, and that the SVR4.0 version will be a
little different than this one.

/proc is initialized by:

        # mount -f PROC /proc /proc

     The `-f PROC' tells mount the filesystem type, and this
argument is required if the type is different than the standard
`S5'.  There is an entry in /etc/fstab for this, so /proc is
mounted normally on system bootup.

     Once mounted, it appears largely like any other filesystem.
When you look at the /proc directory, you see five-digit
filenames, each of which represents a process.  This is part of
an ls listing:

  13 -rw-------   1 root     root        6144 Oct 27 19:22 00000
 155 -rw-------   1 root     root       77824 Oct 27 19:22 00001
 163 ----------   1 root     root       81920 Oct 27 19:22 04295
1005 -rw-------   1 root     isql      509952 Oct 27 19:22 04307
 121 -rw-------   1 root     root       61440 Oct 27 19:22 04309
 125 -rw-------   1 martin   mg         63488 Oct 27 19:22 04321
 125 -rw-------   1 shirley  mg         63488 Oct 27 19:22 04323
 117 -rw-------   1 root     root       59392 Oct 27 19:22 04325
 117 -rw-------   1 root     root       59392 Oct 27 19:22 04326

     In each case, the PID is represented by the filename.  The
owner and group shown are the effective uid/gid, and I believe
the size represents the current memory usage of the process.  The
date is the time the process started, and the permissions are a
little fuzzy.  I do know that I am generally permitted to open my
own process, but there are circumstances where I can't even do
that.  It is my understanding that there are never group or other
permissions available, only owner.

     You can't create or link or remove or chmod any of these
files, you can only open them.  Once the file is open, one may
read or write to any byte in the process image (say, to set a
breakpoint), plus do a wide variety of ioctl operations.

     The file /usr/include/sys/fs/prioctl.h contains the
information required to access this facility, and I'll mention
some of the things available.

     One may obtain proc and user structs, as well as a call that
returns a struct full of info that is sufficient for doing a fast
and portable ps(1) (it's called PIOCPSINFO).  There is a handful
of ioctls related to setting signal dispositions and such, and it
strikes me that it is quite robust.

     A program has full access to the process register set, plus
info about memory mapping and such.  There is even a call that
returns the file descriptor of the actual text image, so it is
possible to read things like the a.out header or the symbol table
without knowing the pathname.

     Generally, /proc provides everything needed to make a really
cool debugger, and it is a certainty that somebody in AT&T is
working on one.  Note that unlike Sys V ptrace, a debugged
process need not be a direct child of the debugger -- it's
possible to debug an already-running process as long as you have
permission to do so (you are root or it's your process).

     This group (plus comp.unix.wizards) occasionally carries a
discussion of the truss(1) program.  This is a system-call
tracer, and according to legend, it can print each system call
with arguments and return values.  This program is not found on
the machine I use, but I've put together one of my own (*very*
rough) and it is really amazing how much this kind of thing can
tell you about a running program.  If anybody out there (say, the
3B15 group) is listening, I would really love to get a copy of
truss for the 3B15.

     /proc and truss(1) (plus probably some other stuff) will be
available in System V Release 4.0, and from what I hear, its
inclusion in the System V Release 3.1.1 distribution for the 3B15
was informal (actually, it was called a mistake).  It is not
available in Sys V Release 3.1.1 for the 3B2, and I'm pretty sure
it's not in SVR3.2 -- I'm loading 3.2 on a /600 now.

     I have a little program that stops/starts arbitrary
processes that I'll pass source along to those who want it.
Anybody with info on /proc is encouraged to post or mail to me,
as I'll summarize and keep a repository for this kind of digging.

     Steve

-- 
Steve Friedl    V-Systems, Inc.  +1 714 545 6442    3B2-kind-of-guy
friedl at vsi.com     {backbones}!vsi.com!friedl    attmail!vsi!friedl
----Nancy Reagan on 120MB SCSI cartridge tape: "Just say *now*"----