PROC(3) 						     Library Functions Manual							   PROC(3)

NAME

       proc - running processes

SYNOPSIS

       bind #p /proc

       /proc/n/ctl
       /proc/n/mem
       /proc/n/note
       /proc/n/noteid
       /proc/n/notepg
       /proc/n/proc
       /proc/n/segment
       /proc/n/status
       /proc/n/text
       /proc/n/wait
       ...

DESCRIPTION

       The  proc  device serves a two-level directory structure.  The first level contains numbered directories corresponding to pids of live pro-
       cesses; each such directory contains a set of files representing the corresponding process.

       The mem file contains the current memory image of the process.  A read or write at offset  o,  which  must  be  a  valid  virtual  address,
       accesses  bytes from address o up to the end of the memory segment containing o.  Kernel virtual memory, including the kernel stack for the
       process and saved user registers (whose addresses are machine-dependent), can be accessed through mem.  Writes are permitted only while the
       process is in the Stopped state and only to user addresses or registers.

       The  read-only  proc  file  contains the kernel per-process structure.  Its main use is to recover the kernel stack and program counter for
       kernel debugging.

       The read-only segment file contains a textual display of the memory segments attached to the process.  Each line has multiple  fields:  the
       type of segment (Stack, Text, Data, Bss, etc.); one-letter flags such as R for read-only, if any; starting virtual address, in hexadecimal;
       ending virtual address, and reference count.

       The read-only status file contains a string with eight fields, each followed by a space.  The fields are: the process name and  user  name,
       each  27  characters left justified; the process state, 11 characters left justified (see ps(1)); the six 11-character numbers also held in
       the process's #c/cputime file, and the amount of memory used by the process, except its stack, in units of 1024 bytes.

       The text file is a pseudonym for the file from which the process was executed; its main use is to recover the symbol table of the process.

       The wait file may be read to recover Waitmsg records from the exiting children of the process.  If the process has no extant children, liv-
       ing or exited, a read of wait will block.  It is an error for a process to attempt to read its own wait file when it has no children.  When
       a process's wait file is being read, the process will draw an error if it attempts a wait system call; similarly, if a process is in a wait
       system call, its wait file cannot be read by any process.

       Textual	messages written to the ctl file control the execution of the process.	Some require that the process is in a particular state and
       return an error if it is not.

       stop	 Suspend execution of the process, putting it in the Stopped state.

       start	 Resume execution of a Stopped process.

       waitstop  Do not affect the process directly but, like all other messages ending with stop, block the process writing the  ctl  file  until
		 the  target process is in the Stopped state or exits.	Also like other stop control messages, if the target process would receive
		 a note while the message is pending, it is instead stopped and the debugging process is resumed.

       startstop Allow a Stopped process to resume, and then do a waitstop action.

       hang	 Set a bit in the process so that, when it completes an exec(2) system call, it will enter the Stopped state before  returning	to
		 user mode.  This bit is inherited across a fork(2).

       nohang	 Clear the hang bit.

       kill	 Kill the process the next time it crosses the user/kernel boundary.

       Strings	written  to  the note file will be posted as a note to the process (see notify(2)).  The note should be less than characters long;
       the last character is reserved for a terminating NUL character.	A read of at least characters will retrieve the oldest note posted to  the
       process	and  prevent  its delivery to the process.  The notepg file is similar, but the note will be delivered to all the processes in the
       target process's note group (see fork(2)).  However, if the process doing the write is in the group, it will not  receive  the  note.   The
       notepg file is write-only.

       The textual noteid file may be read to recover an integer identifying the note group of the process (see RFNOTEG in fork(2)).  The file may
       be written to cause the process to change to another note group, provided the group exists and is owned by the same user.

FILES

       /sys/src/9/*/mem.h
       /sys/src/9/*/dat.h

SEE ALSO

       debugger(2), mach(2), cons(3)

SOURCE

       /sys/src/9/port/devproc.c

																	   PROC(3)