ref: 2b99422480d596ebc26921c87c6bb81a07949f3e
dir: /ch2.ms/
.so tmacs
.BC 2 "Programs and Processes
.BS 2 "Processes
.LP
A running program is called a
.B process .
.ix "running program
The name
.I program
is not used to refer to a running program
because both concepts differ. The difference is the same that you may find
between a cookie recipe and a cookie.
A program is just a bunch of data, and not something
alive. On the other hand, a process is a living program. It has a set of
registers including a program counter and a stack. This means that it has
a
.I "flow of control"
.ix "flow~of~control
that executes one instruction after another as you know.
.PP
The difference is quite clear if you consider that you may execute simultaneously
the same program more than once. For example, figure [[!three processes!]]
shows a window
system with three windows. Each one has its own shell.
This means that we have three processes running
.CW /bin/rc ,
although there is only a single program for those processes. Namely, that kept
stored in the file
.CW /bin/rc .
Furthermore, if we change the working directory in a shell, the other two ones
remain unaffected. Try it! Suppose that the program
.CW rc
.ix "current directory
keeps in a variable the name for its working directory. Each shell process has its own
.I "current working directory
variable. However, the program had only one such variable declared.
.LS
.BP rio3.ps
.R
.LE F Three \f(CW/bin/rc\fP processes. But just one \f(CW/bin/rc\fP.
.PP
So, what is a process? Consider all the programs you made. Pick one of them.
When you execute your program and it starts execution, it can run \fBindependently\fP
.ix "independent execution
of all other programs in the computer. Did you have to take into account
other programs like the window system, the system shell, a clock, a web
navigator, or any other just to write your own (independent) program and
execute it? Of course not. A brain with the size of the moon would be needed
to be able to take all that into account. Because no such brains exist,
operating systems provide the process abstraction. To let you write and
run one program and
.I forget
about other running programs.
.PP
Each process gets the
.I illusion
of having its own processor. When you write programs, you think that the machine executes
one instruction after another. But you always think that all the instructions belong to your
program. The implementation of the process abstraction included in your system provides
this fantasy.
.PP
When machines have several processors, multiple programs can be executed
in \fBparallel\fP.
.ix "parallel execution
i.e., at the same time. Although this is becoming common, many machines have
just one processor. In some cases we can find machines with two or four ones.
But in any case, you run many more programs than processors are installed.
Count the number of windows at your terminal. There is at least one program per window.
You do not have that many processors.
.PP
What happens is that the operating system makes arrangements to let each
program execute for just some time. Figure [[!concurrent execution!]] depicts the
memory for a system with three processes running. Each process gets its own
set of registers, including the program counter. The figure is just a snapshot made
.ix "program counter
at a point in time. During some time, the process 1 running
.CW rio
may be allowed to proceed, and it would execute its code. Later, a hardware timer
set by the system may expire, to let the operating system know that the time for
this process is over. At this point, the system may
.I jump
to continue the execution of process 2,
running
.CW rc .
After the time for this process expires, the system would jump to continue execution
for process 3, running
.CW rio .
When time for this process expires, the system may jump back to process 1, to continue
where it was left at.
.LS
.PS 4.5cm
.CW
.ps -4
boxwid=.8
boxht=.2
arrowhead=7
down
[
[ right
P1: [ down
box invis "..."
box invis "addl bx, di"
P: box invis "addl bx, si"
box invis "subl $4, di"
box invis "movl bx, cx"
box invis "..."
]
box dashed wid 1 ht 6*boxht at last []
box invis wid 1 "\fRRio\fP" "\fR(process #1)\fP"
move 1
P2: [ down
box invis "..."
box invis "cmpl si, di"
box invis "jls label"
box invis "movl bx, cx"
P: box invis "addl bx, si"
box invis "..."
]
box dashed wid 1 ht 1.2 at last []
box invis wid 1 "\fRRio\fP" "\fR(process #3)\fP"
arrow <- from P1.P.w left .4 "PC" above
arrow <- from P2.P.w left .4 "PC" above
]
move
[ right
P3: [ down
box invis "..."
box invis "addl bx, di"
box invis "addl bx, si"
P: box invis "subl $4, di"
box invis "movl bx, cx"
box invis "..."
]
box dashed wid 1 ht 6*boxht at last []
box invis wid 1 "\fRRc\fP" "\fR(process #2)\fP"
move .5
arrow <- from P3.P.w left .4 "PC" above
]
]
.B
box wid 6 ht 3.5 at last []
box invis ht .75 "System" "Memory" with .se at last box.se
reset boxwid, boxht, arrowhead
.R
.ps +4
.PE
.LE F Concurrent execution of multiple programs in the same system.
.PP
All this happens behind the scenes. The operating system program knows
that there is a single flow of control per processor, and jumps from one
place to another to transfer control. For the users of the system, all that
matters is that each process executes independently of other ones, as if it
had a single processor for it.
.PP
Because all the processes appear to execute
simultaneously, we say they are
.B "concurrent processes" .
In some cases, they will really execute in
.B parallel
when each one can get a real processor. In most cases, it would be a
.B "pseudo-parallel execution" .
For the programmer, it does not matter. They are just concurrent
processes that seem to execute simultaneously.
.PP
In this chapter we are going to explore the process we obtain when we
execute a program. Before doing so, it is important to know what's in a program
and what's in a process.
.BS 2 "Loaded programs
.ix "loaded program
.LP
When a program in source form is compiled and linked, a binary file is generated.
This file
keeps all the information needed to execute the program, i.e., to create
a process that runs it. Different parts of the binary file that keep different type
of information are called sections. A binary file starts with a few words
that describe the following sections. These initial
words are called a header, and usually show the architecture where the
binary can run, the size and offset in the file for various sections.
.ix "binary file
.ix "compiler
.ix "linker
.PP
One section (i.e., portion) of the file contains the program text (machine
instructions). For initialized global variables of the program,
another section contains their initial values. Note that the system knows
.I nothing
about the meaning of these values.
For uninitialized variables, only the total memory size required to hold
them is kept in the file. Because they
have no initial value, it makes no sense to keep that in the file. Usually, some
information to help debuggers is kept in the file as well, including the strings
with procedure and symbol names and their addresses.
.PP
In the last chapter we
saw how
.CW nm
can be used to display symbol information in both object and binary files.
But it is important to notice that only your program code knows the meaning of
the bytes in the program data (i.e., the program knows what a variable is).
For the system, your program data has no meaning. \fBThe system knows nothing\fP
about your program; you are the one who knows. The program
.CW nm
can display information about the binary file because it looks at the symbol
table stored in the binary for debugging purposes.
.PP
We can see this if we remove
the symbol table from our binary for the
.CW take.c
program. The command
.CW strip
.ix [strip]
removes the symbol table. To find the binary file size,
.ix "symbol table
we can use option
.CW -l
for
.I ls ,
which (as you know) lists a long line of information for each file, including the size in bytes.
.ix "[ls] flag~[-l]
.P1
; !!ls -l 8.take
--rwxr-xr-x M 19 nemo nemo 36348 Jul 6 22:49 8.take
; strip 8.take
; ls -l 8.take
--rwxr-xr-x M 19 nemo nemo 21713 Jul 6 22:49 8.take
.P2
.LP
The number after the user name and before the date is the file size in bytes.
The binary file size changed from 36348 bytes down to 21713 bytes. The
difference in size is due to the symbol table.
And without the symbol table,
.CW nm
knows nothing. Just like the system.
.P1
; nm 8.take
;
.P2
.LP
Well, of course the system has a convention regarding which one is the address where
to start executing the program. But nevertheless, it does not care much about which
code is in there.
.PP
A program stored in a file is different from the same program stored in memory
while it runs. They are related, but they are not the same.
Consider this program. It does nothing, but has a global variable of one megabyte.
.so progs/global.c.ms
.ix [global.c]
.ix "global variable
.LP
Assuming it is kept at
.CW global.c ,
we can compile it and use the linker option
.CW -o
to specify that the binary is to be generated in the new file
.CW 8.global .
It is a good practice to name the binary file for a program after the program name,
specially when multiple programs may be compiled in the same directory.
.P1
; 8c -FVw global.c
; 8l -o 8.global global.8
.P2
.LP
.P1
; ls -l 8.global global.8
--rwxr-xr-x M 19 nemo nemo 3380 Jul 6 23:06 8.global
--rw-r--r-- M 19 nemo nemo 328 Jul 6 23:06 global.8
.P2
.LP
Clearly, there is no room in the 328 bytes of the object file for the
.CW global
array, which needs one megabyte of storage. The explanation is that only the
size required to hold the (not initialized) array is kept in the file. The binary file
does not include the array either (change the array size, and recompile to check
that the size of the binary file does not change).
.PP
When the shell asks the system (making a system call) to execute
.CW 8.global ,
the system \fBloads the program\fP
.ix "program loader
into memory. The part of the system (kernel) doing this is called the \fBloader\fP.
How can the system load a program? By reading the information kept in the binary:
.IP •
The header in the binary file reports the memory size required
for the program text, and the file keeps the memory image of that text. Therefore,
.ix "memory image
the system can just copy all this into memory. For a given system and architecture,
there is a convention regarding which addresses the program must use. Therefore,
the system knows where to load the program.
.IP •
The header in the binary reports the memory size required for initialized
variables (globals) and the file contains a memory image for them. Thus, the
system can copy those bytes to memory. Note that the system has no idea
regarding where does one variable start or how big it is. The system only knows
how many bytes it has to copy to memory, and at which address should they be
copied.
.IP •
For uninitialized global variables, the binary header reports their total size.
The system allocates that amount of memory for the program. That is all it
has to do. As a courtesy, Plan 9 guarantees that such memory is initialized with
all bytes being zero. This means that all your global variables are initialized to
null values by default. That is a good thing, because most programs will misbehave
if variables are not properly initialized, and null values for variables seem to be a
nice initial value by default.
.LP
We saw how the program
.CW nm
prints addresses for symbols. Those addresses are memory addresses that
are only meaningful when the program has been loaded. In fact, the Plan 9 manual
refers to the linker as the
.B loader .
The addresses are
.ix "virtual address space
.ix "virtual memory
.I virtual
memory addresses, because the system uses the virtual memory hardware to
keep each process in its own virtual address space. Although virtual, the addresses are
absolute, and not relative (offsets) to some particular origin.
Using
.CW nm
we can learn more about how the memory of a loaded program looks like.
Option
.CW -n
.ix "[nm] flag~[-n]
asks
.CW nm
to sort the output by symbol address.
.P1
; nm -n 8.global
1020 T main
1033 T _main
1073 T atexit
10e2 T atexitdont
1124 T exits
1180 T _exits
1188 T getpid
11fb T memset
122a T lock
12e7 T canlock
130a T unlock
1315 T atol
1442 T atoi
1455 T sleep
.P2
.P1
145d T open
1465 T close
146d T read
14a0 T _tas
14ac T pread
14b4 T etext
2000 D argv0
2004 D _tos
2008 D _nprivates
200c d onexlock
2010 D _privates
2014 d _exits
2024 B edata
2024 B onex
212c B global
10212c B end
.P2
.LP
Figure [[!memory image!]] shows the layout of memory for this program when
loaded. Looking at the output of
.I nm
we can see several things. First, the program code uses addresses starting
at 0x1020 up to 0x14b4.
.PP
The last symbol in the code is
.CW etext ,
.ix [etext]
which is a symbol defined by the linker to let you know where the end of text is.
Data goes from address 0x2000 up to address 0x10212c. There is a symbol
called
.CW end ,
.ix [end]
also defined by the linker, at the end of the data. This symbol lets you know where
the end of data is. This symbol is not to be confused with
.CW edata ,
.ix [edata]
which reports the address where initialized data terminates.
.LS
.PS
boxwid=.7
boxht=.5
.ps -2
T: [ down
box invis "\fIText segment\fP"
box "Program" "text"
]
D: [ down
box invis "\fIData segment\fP"
box "Initialized" "data"
]
B: [ down
box invis "\fIBSS segment\fP"
box wid 3*boxwid "Uninitialized" "data"
]
[ down
box invis
box invis "..."
]
[ down
box invis "\fIStack segment\fP"
box "stack"
]
down
boxht=.2
linewid=.2
.CW
line <- from T.sw ; box invis "0x0"
line <- from T.se ; box invis "etext"
line <- from D.se ; box invis "edata"
line <- from B.se ; box invis "end"
.R
reset boxht, linewid, boxwid
.ps +2
.PE
.LE F Memory image for the \f(CWglobal\fP program.
.PP
In decimal, the address for
.CW end
is 1.057.068 bytes! That is more than 1 Mbyte, which is a lot of memory for a program
that was kept in a binary file of 3 Kbytes. Can you see the difference?
.PP
And there is more. We did not
take into account the program stack. As you know, your program needs a stack to execute.
That is the place in memory used to keep track of the chain of function calls being made,
to know where to return, and to maintain the values for function arguments and local variables.
Therefore, the size of the program when loaded
into memory will be even larger. To know how much memory a program will consume,
use
.I nm ,
do not list the binary file.
.PP
The memory of a loaded program, and thus that of a process, is
arranged as shown in figure [[!memory image!]]. But
that is an invention of the operating system. That is the abstraction supplied
by the system, implemented using the virtual memory hardware, to make your
life easier. This abstraction is called
.B "virtual memory" .
A process believes that it is the only program loaded in memory. You
can notice by looking at the addresses shown by
.CW nm .
All processes running such
program will use the same addresses, which are absolute (virtual) memory addresses.
And more than just one of such processes might run simultaneously in the same
computer.
.PP
The virtual memory of a process in Plan 9 has several, so called,
.I segments .
This is also an abstraction of the system and has few to do with the segmentation
hardware found at some popular processors. A
.B "memory segment"
is a portion of contiguous
memory with some properties. Segments used by a Plan 9 process are:
.IP •
The
.B "text segment" .
It contains instructions that can be executed but not modified. The hardware is
used by the system to enforce these permissions. The memory is initialized by
the system with the program text (code) kept within the binary file for the program.
.IP •
The
.B "data segment" .
It contains the initialized data for the
program. Protection is set to allow both read and write operations on it,
but you cannot execute instructions on it. The memory is initialized by the system
using the initialized data kept within the binary file for the program.
.IP •
The uninitialized data
segment, called
.B "bss segment"
is almost like the data segment. However, this one is initialized by zeroing
its memory. The name of the segment comes from an arcane instruction used to
implement it on a machine that no longer exists.
How much memory is given depends on the size recorded in the binary
file. Moreover, this segment can
.I grow ,
by using a system call that allocates more memory for it. Function libraries like
.CW malloc
.ix [malloc]
cause this segment to grow when they consume all the available memory in this segment. This is
the reason for the
.I gap
between this segment and the stack segment (shown in figure [[!memory image!]]), to leave room
for the segment to grow.
.IP •
The
.B "stack segment"
is also used for reading and writing memory. Unlike other segments, this segment
seems to grow automatically when more space is used. It is used to keep the stack
for the process.
.LP
All this
is important to know because it has a significant impact on your programs and processes.
Usually, not all the code is loaded at once from the binary file into the text (memory)
segment. Binaries are copied into memory one
virtual memory page at a time as demanded by references to memory addresses.
This is called
.B "demand paging" ,
(or loading on demand).
.ix "loading on~demand"
It is important to know this because, if you remove a binary file for a program that
is executing, the corresponding process may get broken if it needs a part of the
program that was not yet loaded into memory. And the same might happen if
you overwrite a binary file while a process is using it to obtain its code!
.PP
Because memory is
.I virtual ,
and is only allocated when first used, any unused part of the BSS
segment is free! It consumes no memory until you touch it. However, if
you initialized it with a loop, all the memory will be allocated. One particular
case when this may be useful is when you implement large hash tables
that contain few elements (called
.I sparse ).
You might implement them using a huge array,
not initialized. Because it is not initialized, no physical memory will be allocated
for the array, initially. If the program uses later
a portion of the array for the first time, the system
will allocate memory and zero it. The array entries would be all nulls.
Therefore, in this example, initializing by hand the array
would have a big impact on memory consumption.
.BS 2 "Process birth and death
.ix "process birth
.ix "process death
.LP
Programs are not
.I called ,
they are
.I executed .
Besides, programs do not
.I return ,
their processes terminate when they want or when they misbehave. Being this said,
we can supply arguments to programs we run, to control what they do.
.ix "program arguments
.PP
When the shell asks the system to execute a program,
after it has been loaded into memory, the system provides a flow of control for it.
This means just that processor registers are initialized for the new
running program, including the program counter and stack pointer, along with
an initial (almost empty) stack.
When we compile a C program, the loader puts
.CW main
.ix [main]
.ix "program entry point
at the address where the system will start executing the code. Therefore, our
C programs start running at
.CW main .
The arguments supplied to this program (e.g., in the shell command line)
are copied by the system to the stack for the new program.
.PP
The arguments given to the
.CW main
function of a program are an array of strings (the argument vector,
.CW argv )
and the number of strings kept
in the array. We can write a program to print its arguments.
.so progs/echo.c.ms
.ix [echo.c]
.LP
If we execute it we can see which arguments are given to the program for
a particular command line:
.P1
; 8c -FVw echo.c
; 8l -o 8.echo echo.8
; ./8.echo one little program
0: ./8.echo
1: one
2: little
3: program
;
.P2
.LP
There are several things to note here. First, the first argument supplied to
the program is the program name! More precisely, it is the command name as given
to the shell. Second, this time we gave a relative path as a command name.
Remember,
.CW ./8.echo ,
is the file
.CW 8.echo
within the current working directory for our shell.
which is a relative path. And that was the value of
.ix "relative path
.CW argv[0]
.ix [argv]
for our program. Programs know their name by looking at
.CW argv[0] ,
which is very useful to print diagnostic messages while letting the user know
which program was the one that had a problem.
.PP
There is a standard command in Plan 9 that is almost the same,
.CW echo .
.ix [echo]
This command prints its arguments separated by white space and a new line.
The new line can be suppressed with the option
.CW -n .
.ix "[echo] flag~[-n]
.P1
; echo hi there
hi there
;
; echo -n hi there
hi there;
.P2
.LP
Note the shell prompt right after the output of echo. Despite being simple,
echo is invaluable to know which arguments a program would get, and to
generate text strings by using echo to print them.
.PP
Our program is not a perfect echo. At least, the standard
.CW echo
has the flag
.CW -n ,
to ask for a precise echo of its arguments, without the addition of the final
new line. We could add several options to our program. Option
.CW -n
may suppress the print of the additional new line, and option
.CW -v
may print brackets around each argument, to let us know precisely where does
an argument start and where does it end. Without
any option, the program might behave just like the standard tool and print one argument
after another. The problem is that the user may call the program in any of the following
ways, among others:
.P1
8.echo repeat after me
8.echo -n repeat after me
8.echo -v repeat after me
8.echo -n -v repeat after me
8.echo -nv repeat after me
.P2
.LP
It is customary that options may be combined in any of the ways shown. Furthermore,
the user might want to echo just
.CW -word- ,
and echo might be confused because it would think that
.CW -word-
was a set of options. The standard procedure is to do it like this.
.P1
8.echo -- -word--
.P2
.ix "option [--]
.LP
The double dash indicates that there are no more options. Isn't it a burden to process
.CW argc
and
.CW argv
to handle all these combinations? That is why there are a set of macros to help (macros are definitions
given to the C preprocessor, that are replaced with some C code before actually compiling).
The following program is an example.
.so progs/aecho.c.ms
.ix [aecho.c]
.LP
The macros
.CW ARGBEGIN
.ix [ARGBEGIN]
and
.CW ARGEND
.ix [ARGEND]
loop through the argument list, removing and processing options. After
.CW ARGEND ,
both
.CW argc
and
.CW argv
reflect the argument list
.I without
any option. Between both macros, we must write the body for a
.CW switch
statement (supplied by
.CW ARGBEGIN ),
with a
.CW case
per option. And the macros take care of any feasible combination of flags in the
arguments. Here are some examples of how can we run our program now.
.P1
; 8.aecho repeat after me
repeat after me
; 8.aecho -v repeat after me
[repeat] [after] [me]
; 8.aecho -vn repeat after me
[repeat] [after] [me] ; \fIwe gave a return here.\fP
; 8.aecho -d repeat after me
usage: 8.aecho [-nv] args
; 8.aecho -- -d repeat after me
-d repeat after me
.P2
.LP
In all but the last case,
.CW argc
is 3 after
.CW ARGEND ,
and
.CW argv
holds just
.CW repeat ,
.CW after ,
and
.CW me .
.PP
Another convenience of using these macros is that they initialize the global variable
.CW argv0
.ix [argv0]
to point to the original
.CW argv[0]
in
.CW main ,
that is, to point to the name of the program. We used this when printing the diagnostic
about how the program must be used, which is the custom when any program is
called in a erroneously way.
.PP
In some cases, an option for a program carries an argument. For example, we might
.ix "option argument
want to allow the user to specify an alternate pair of characters to use instead of
.CW [
and
.CW ]
when echoing with the
.CW -v
option. This could be done by adding an option
.CW -d
to the program that carries as its argument a string with the characters to use. For
example, like in
.P1
8.aecho -v -d"" repeat after me
.P2
.LP
This can be done by using another macro, called
.CW ARGF .
.ix [ARGF]
This macro is used within the
.CW case
for an option, and it returns a pointer to the option argument (the rest of the argument
if there are more characters after the option, or the following argument otherwise).
The resulting program follows.
.so progs/becho.c.ms
.LP
And this is an example of use for our new program.
.P1
; 8.becho -v -d"" repeat after me
"repeat" "after" "me"
; 8.becho -vd "" repeat after me \fRnote the space before the ""\fP
"repeat" "after" "me"
; 8.becho -v
; 8.becho -v -d
usage: 8.becho [-nv] [-d delims] args
.P2
.LP
A missing argument for an option usually means that the program
calls a function to terminate (e.g.,
.CW usage ),
.ix [usage]
the macro
.CW EARGF
.ix [EARGF]
is usually preferred to
.CW ARGF .
We could replace the case for our option
.CW -d
to be as follows.
.P1
case 'd':
delims = EARGF(usage());
if (strlen(delims) < 2)
usage();
break;
.P2
.LP
And
.CW EARGF
would execute the code given as an argument when the argument is not supplied. In
our case, we had to add an extra
.CW if ,
to check that the argument has at least the two characters we need.
.PP
Most of the Plan 9 programs that accept multiple options use these macros to
process their argument list in search for options. This means that the invocation syntax
.ix "command invocation syntax
is similar for most programs. As you have seen, you may combine options in a single
argument, use multiple arguments, supply arguments for options immediately after
the option letter, or use another argument, terminate the option list by giving a
.CW --
argument, and so on.
.PP
As you have probably noticed after going this far,
a process terminates by a call to
.CW exits ,
see
.I exits (2)
.ix [exits]
for the whole story. This system call terminates the calling process. The
.ix "process termination
process may leave a single string as its legacy, reporting what it has to say.
Such string reports the process
.B "exit status" ,
that is, what happen to it.
If the string is null, it means by convention that everything went well for
the dying process, i.e., it could do its job. Otherwise, the convention is
that string should report the problem the process had to complete its job.
For example,
.so progs/sic.c.ms
.ix [sic.c]
.LP
would report
.CW sic!
to the system when
.CW exits
terminates the process. Here is a run
that shows that by echoing
.CW $status
.ix [$status]
we can learn how it went to this depressive program.
.P1
; 8.sic
; echo $status
8.sic 2046: sic!
;
.P2
.LP
Commands exit with an appropriate status depending on what happen
to them. Thus,
.CW ls
reports success as its status when it could list the files given as arguments, and
it reports failure otherwise. In the same way,
.CW rm
reports success when it could remove the file(s) indicated, and failure otherwise.
And the same applies for other commands.
.PP
We lied before when we said that a program starts running at
.CW main ,
it does not. It starts running at a function that calls
.CW main
and then (when
.CW main
returns), this function calls
.CW exits
to terminate the execution. That is the reason why a process ceases
existing when the main function of the program returns. The process makes
a system call to terminate itself. There is no magic here, and a process may
not cease existing merely because a function returns. A flow of control does
not vanish, the processor always keeps on executing instructions. However,
because processes are an invention of the operating system, we can use
a system call that kills the calling process. The system deallocates its
resources and the process is history. A process is a data type after all.
.PP
In few words, if your program does not call
.CW exits ,
the function that calls
.CW main
will do so when
.CW main
returns. But you better call
.CW exits
in your program. Otherwise, you cannot be sure about what value is being used
as your exit status.
.BS 2 "System call errors
.LP
.ix "system call error"
In this chapter and the following ones we are going to make a lot of system calls from
programs written in C. In many cases, there will be no problem and a system
call we make will be performed. But in other cases we will make a mistake
and a system call will not be able to do its work. For example, this will happen
if we try to change our current working directory and supply a path that does not exist.
.PP
Almost any function that we call (and system calls are functions) may have problems to
complete its job. In Plan 9, when a system call encounters an error or is not
able to do its work, the function returns a value that alerts us of the error condition.
Depending on the function, the return value indicating the error may be one or
another. In general, absurd return values are used to report errors.
.PP
For example, we will see how the system call
.CW open
returns a positive small integer. However, upon failure, it returns -1. This is the convention
for most system calls returning integer values. System calls that
return strings will return a null string when they fail, and so on. The manual pages
report what a system call does when it fails.
.PP
You must \fBalways check for error conditions\fP.
If you do not check that a system call could do its work, you do not know if
it worked. Be warned, not checking for errors is like driving blind, and it will
surely put you into a debugging Inferno (limbo didn't seem bad enough).
.ix debugging
An excellent book, that anyone programming should read, which teaches
practical issues regarding how to program is [.practice programming.].
.ix "programming practice
.PP
Besides reporting the error with an absurd return value from the system call,
Plan 9 keeps a string describing the error. This
.B "error string"
is invaluable information for
fixing the problem. You really want to print it out to let the user know what happen.
.PP
There are several ways of doing so. The more convenient one is using the format
“\f(CW%r\fP” in
.ix [%r] format specifier
.CW print .
.ix [print]
This instructs
.CW print
to ask Plan 9 for the error string and print it along with other output.
This program is an example.
.so progs/err.c.ms
.ix [err.c]
.LP
Let's run it now
.P1
; 8.err
chdir failed: 'magic' file does not exist
.P2
.LP
The program tried to use
.CW chdir
.ix [chdir]
to change its current working directory to
.CW magic .
Because it did not exist, the system call failed and returned
.CW -1 .
A good program would always check for this condition, and then report
the error to the user. Note the use of
.CW %r
in
.CW print
and compare to the output produced by the program.
.PP
If the program cannot proceed because of the failure, it is sensible
to terminate the execution indicating that the program failed. This is
so common that there is a function that both prints a message and
exits. It is called
.CW sysfatal ,
.ix [sysfatal]
and is used like follows.
.P1
if (chdir("magic") < 0)
sysfatal("chdir failed: %r");
.P2
.LP
In a few cases you will need to obtain the error string for a system call that
failed. For example, to modify it and print a customary diagnostic message.
The system call
.CW rerrstr
.ix [rerrstr]
reads the error string. It stores the string at the buffer you supply. Here
is an example
.P1
char error[128];
\fI ... \fP
rerrstr(error, sizeof error);
.P2
.LP
After the call,
.CW error
contains the error string.
.PP
A function implemented to be placed in a library also needs to report errors.
If you write such function, you must think how to do that. One way is to use
the same mechanism used by Plan 9. This is good because it allows any
programmer using your library to do exactly the same to deal with errors,
no matter if the error is being reported by your library function or by Plan 9.
.PP
The system call
.CW werrstr
.ix [werrstr]
writes a new value for the error string. It is used like
.CW print .
Using it, we can implement a function that
.CW pops
an element from a stack and reports errors nicely:
.P1
int
pop(Stack * s)
{
if (isempty(s)){
werrstr("pop on an empty stack");
return -1;
}
\fI ... do the pop otherwise ... \fP
}
.P2
.LP
Now, we could write code like the following,
.P1
\fI...\fP
if (pop(s) < 0){
print("pop failed: %r\en");
\fI...\fP
}
.P2
.LP
and, upon an error in
.CW pop
this would print something like:
.P1
pop failed: pop on an empty stack
.P2
.BS 2 "Environment
.LP
Another way to supply “arguments” to a process is to define
.B "environment variables" .
Each process is supplied with a set of \fIname\fP=\fIvalue\fP
strings, that are known as environment variables. They are used to customize
the behavior of certain programs, when it is more convenient to define
an environment variable than to give a command line argument every time we
run a program. Usually, all processes running in the same
.ix [rio]
window share
.ix window
.ix "process group
the environment variables.
.PP
For example, the variable
.CW home
.ix "home directory
has the path for your home directory as its value. The command
.CW cd
uses this variable to know where your home is. Otherwise, how could
it know what to do when given no arguments?
Both names and values of environment variables are strings.
Remember this.
.PP
We can define environment variables in a shell command line by using an equal sign.
Later, we can use the shell to refer to the value of any environment variable.
After reading each command line, the shell replaces each word starting with a
dollar sign with the value of the environment variable whose name follows the
dollar. For example, the first command in the following session defines the variable
.CW dir :
.ix "command line
.P1
; dir=/a/very/long/path
; cd $dir
; pwd
/a/very/long/path
;
.P2
The second command line used
.CW $dir ,
and therefore, the shell replaced the string
.CW $dir
with the string that is the value of the
.CW dir
environment variable:
.CW /a/very/long/path .
Note that
.CW cd
knows nothing about
.CW $dir .
We can see this using
.CW echo ,
because we know it prints the arguments received verbatim.
.P1
; echo $dir
/a/very/long/path
;
.P2
.LP
The next two commands do the same. However, one receives one argument and
the other does not. The output of
.CW pwd
.ix [pwd]
would be the same after any of them.
.P1
; cd $home
; cd
.P2
.LP
In some cases it is convenient to define an environment variable just for a command.
This can be done by defining it in the same command line, before the command, like
in the following example:
.P1
; temp=/tmp/foobar echo $temp
/tmp/foobar
; echo $temp
;
.P2
.LP
At this point, we can understand what
.CW $status
.ix [$status]
.ix "exit status
means. It is the value of the environment variable
.I status .
This variable is updated by the shell once it finds out how it went
to the last command it executed. This is done before prompting for
the next command. As you know, the value of this variable would be
the string given to
.I exits
by the process running the command.
.PP
Another interesting variable is
.CW path .
.ix [$path]
.ix command
This variable is a list of paths where the shell should look for executable files
to run the user commands. When you type a command name that does not start
with
.CW /
or
.CW ./ ,
the shell looks for an executable file relative to each one of the directories listed in
.CW $path ,
in the same order.
If a binary file is found, that is the one executed to run the command. This is the value
of the
.I path
variable in a typical Plan 9 shell:
.P1
; echo $path
. /bin
;
.P2
.LP
It contains the working directory, and
.CW /bin ,
.ix [/bin]
in that order.
If you type
.CW ls ,
the shell tries with
.CW ./ls ,
and if there is no such file, it tries with
.CW /bin/ls .
If you type
.CW ip/ping ,
the shell tries with
.CW ./ip/ping ,
and then with
.CW /bin/ip/ping .
Simple, isn't it?
.PP
Two other useful environment variables are
.CW user ,
.ix [$user]
.ix "user name
which contains the user name, and
.CW sysname ,
.ix [$sysname]
.ix "system name
which contains the machine name. You may define as many as you want.
But be careful. Environment variables are usually forgotten while debugging a
.ix debugging
problem. If some program input value should be a command line argument, use
a command line argument. If somehow you need an environment variable to
avoid passing an argument all the times a program is called, perhaps the command
arguments should be changed. Sensible default values for program arguments
can avoid the burden of having to supply always the same arguments. Command
line arguments make the program invocation explicit,
more clear at first sight, and therefore,
simpler to grasp and debug. On the other hand,
environment variables are used by programs without
the user noticing.
.PP
Because of the syntax in the shell for environment variables, we may have a problem
if we want to run
.I echo ,
or any other program, supplying arguments
containing either the dollar sign, or the equal sign. Both characters
we know are special. This can be done by asking the shell not to do anything with
a string we type, and to take it literally. Just type the string into single quotes and
.ix quoting
the shell will not change anything between them:
.P1
; echo $user
nemo
; echo '$user' is $user
$user is nemo
;
.P2
.LP
Note also that the shell behaves always the same way regarding command
line text. For example, the first word (which is the command name) is not special,
and we can do this
.P1
; cmd=pwd
; $cmd
/usr/nemo
;
.P2
.LP
and use variables wherever we want in command lines. Also, quoting works always
the same way. Let's try with the
.I echo
program we implemented before:
.P1
; 8.echo 'this is' weird
0: echo
1: this is
2: weird
;
.P2
.LP
As you may see,
.CW argv[1]
.ix [argv]
.ix [echo.c]
contains the string
.CW "this is" ,
including the white space. The shell did not split the string into two different
arguments for the command. Because you quoted it! Even the new line can be quoted.
.P1
; echo 'how many
;; lines'
how many
lines
.P2
.LP
The prompt changed because the shell had to read more input, to complete the quoted
string. That is its way of telling us.
Quoting also removes the special meaning of other characters, like the backslash:
.ix "escape character
.ix "backslash
.P1
; echo \e
;; \fIwaiting for the continuation of the line\fP
; \fI...until we press return\fP
\fIecho prints the empty line\fP
; echo '\e'
\e
;
.P2
.LP
To obtain the value for a environment variable, from a C program, we can
use the
.CW getenv
.ix [getenv]
system call. And of course, the program must check out for errors. Even
.CW getenv
can fail. Perhaps the variable was not defined. In this case
.CW getenv
returns a null string.
.so progs/env.c.ms
.ix [env.c]
.LP
Running it yields
.P1
; 8.env
home is /usr/nemo
.P2
.LP
A related call is
.CW putenv ,
.ix [putenv]
which accepts a name and a value, and sets the corresponding environment
variable accordingly. Both the name and value are strings.
.BS 2 "Process names and states
.ix "process name
.ix "process state
.ix "scheduling
.LP
The name of a process is not the name of the program it runs. That is
convenient to know, nevertheless.
Each process is given a unique number by the system when it is created.
That number is called the
.B "process id" ,
or the
.I pid .
.ix pid
The pid identifies, and therefore names, a process.
.PP
The pid of a process is a positive number, and the system tries hard not
to reuse them. This number can be used to name a process when asking
the system to do things to it. Needless to say that this
.I name
is also an invention of the operating system. The shell environment variable
.CW pid
.ix [$pid]
.ix "shell pid"
contains the pid for the shell. Note that its value is a string, not an integer. Useful
for creating temporary files that we want to be unique for a given shell.
.ix "temporary files"
.PP
To know the pid of the process that is executing our program, we can use
.CW getpid :
.ix [getpid]
.so progs/pid.c.ms
.ix [pid.c]
.LP
Executing this program several times may look like this
.P1
; 8.pid
my pid is 345
; 8.pid
my pid is 372
;
.P2
.LP
The first process was the one with pid 345, but we may say as well that
the first process was the 345, for short. The second process started was
the 372.
Each time we run the program we would get a different one.
.PP
The command
.CW ps
(process status)
.ix [ps]
lists the processes in the system. The second field of each line (there is
one per process) is the process id. This is an example
.P1
.ps -2
; ps
nemo 280 0:00 0:00 13 13 1148K Pread rio
nemo 281 0:02 0:07 13 13 1148K Pread rio
nemo 303 0:00 0:00 13 13 1148K Await rio
nemo 305 0:00 0:00 13 13 248K Await rc
nemo 306 0:00 0:00 13 13 1148K Await rio
\fI... more output omitted ...\fP
.ps +2
.P2
.LP
The last field is the name of the program being run by the process. The third field going right
to left is the size of the (virtual) memory being used by the process. You may now know
.ix "process memory
.ix "virtual memory
how much memory a program consumes when loaded.
.PP
The second field on the right is interesting. You see names like
.CW Pread
.ix [Pread]
and
.CW Await .
.ix [Await]
Those names reflect the
.B "process state" .
The process state indicates what the process is doing. For example, the
first processes 280 and 281, running
.CW rio ,
are reading something, and everyone else in the listing above
is awaiting for something to happen. To understand this, it is important to
get an idea of how the operating system implements processes.
.PP
There is only one processor, but there are multiple processes that seem to
run simultaneously. That is the process abstraction. Multiple programs that
.ix process
execute independently of each other. None of them transfer control to
others. However, the processor implements only a single flow of control.
.ix "flow of control
.PP
What happens is that when one process enters the kernel because of a
.ix kernel
.ix "system call
system call, or an interrupt, the system may store the process state (its
registers mostly) and then jump to the previously saved state for another process.
Doing this quickly, with the amazingly fast processors we have today, makes
it appear that all processes can run at the same time.
Each process is given a small amount of processor time, and later, the system
decides to jump to another one. This amount of processor time
is called a
.B quantum ,
and can be 100ms, which is a very long time regarding
the number of machine instructions that you can execute in that time.
.PP
A transfer of control
from one process to another, by saving the state for the old process and
reloading the state for the new one, is called a
.B "context switch" ,
because the state for a process (its registers, stack, etc.) is called its
.B "context" .
But note that it is the kernel the one that transfers control. You do not
include “jumps” to other processes in your programs!
.PP
The part of the kernel
deciding which process runs each time is called the
.B scheduler ,
because it
schedules processes for execution. And the decisions made
by the scheduler to multiplex the processor among processes are collectively
known as
.B scheduling .
In Plan 9 and most other systems, the scheduler is able to move a process out
of the processor even if it does not call the operating system (and gives it a
chance to move the process out). Interrupts are used to do this. Such type of
scheduling is called
.B "preemptive scheduling" .
.PP
With a single processor, just one process may be
.B running
at a time, and many others may be
.B ready
to run. These are two process states, see figure [[!process states!]].
The running process becomes ready
when the system terminates its time in the processor. Then, the system picks
up a ready process to become the next running one. States are just constants
defined by the system to cope with the process abstraction.
.PP
Many times, a process would be reading from a terminal, or from a network
connection, or any other device. When this happens, the process has to wait
for input to come. The process could wait by using a loop, but that would be
a waste of the processor. The idea is that when one process starts waiting for
.ix "busy waiting
input (or output) to happen, the system can switch to another process
and let it run. Input/output
devices are so slow compared with the processor that the machine can execute a lot
of code for other processes
while one is waiting. The time the processor needs to execute some instructions,
compared to the time needed by I/O devices to perform their job, is like
the time you need to move around in your house and the time you
need to go to the moon.
.PP
This idea is central to the concept of
.B multiprogramming ,
which is the name given to the technique that allows multiple programs to
be loaded at the same time on a computer.
.LS
.PS
.ps -2
.R
circlerad=.3
down
X: circle "Running"
move
D: [ right
R: circle "Ready"
line <-
B: circle "Blocked"
]
arrow <-> from X to D.R chop
arrow from X to D.B chop
left ; arrow <- from D.R.w left ; box invis "Birth"
right
arrow from X.e right ; circle "Broken" ; arrow ; D: box invis "Death"
spline -> from X.ne up right then right then to D.nw
.ps +2
.PE
.LE F Process states and transitions between them.
.PP
To let one process wait out of the processor, without considering it as a
candidate to be put into the running state, the process is flagged as
.B blocked .
This is yet another process state. All the processes listed above where
blocked. For example,
.CW Pread
and
.CW Await
mean that the process is blocked (i.e., the former shows that the process is blocked
waiting for a read to complete). When the event a blocked process is waiting for happens, the
process state is changed to ready. Sometime in the future it will be selected
for execution in the processor.
.PP
In Plan 9, the state shown for blocked processes reflects the reason
that caused the process to block. That is why
.CW ps
shows many different states. They are a help to let us know what is happening
to our processes.
.PP
There is one last state,
.B broken ,
which is entered when the process does something illegal (i.e., it
suffers an error). For example, dividing by zero or dereferencing a null pointer
causes a hardware exception (an error). Exceptions are dealt with by the hardware
.ix exception
.ix error
like interrupts are, and the system is of course the handler for these
exceptions. Upon this kind of error, the process enters the broken state. A broken
process will never run. But it will be kept hanging around for debugging until it
dies upon user request (or because there are too many broken processes).
.BS 2 "Debugging
.ix "debugging
.LP
When we make a mistake, and a running program enters the broken state,
it is useful to see what happen. There are several ways of finding out what happen.
To see them, let's write a program that crashes. This program says hello to
the name given as an argument, but it does not check that the argument was
given, nor does it use the appropriate format string for
.CW print .
.so progs/hi.c.ms
.LP
When we compile this program and execute it, this happens:
.P1
.ps -1
; 8.hi
8.hi 788: suicide: sys: trap: fault read addr=0x0 pc=0x000016ff
.ps +1
.P2
.ix trap
.ix fault
.LP
The last line is a message printed by the shell. It was waiting for
.CW 8.hi
to terminate its execution. When it terminated, the shell saw that
something bad happen to the program and printed the diagnostic so we could
know. If we print the value of
the
.CW status
variable, we see this
.P1
; echo $status
8.hi 788: sys: trap: fault read addr=0x0 pc=0x000016ff
.P2
Therefore, the
.I legacy ,
or exit status, of
.ix "exit status
.CW 8.hi
is the string printed by the shell. This status does not proceed from a call to
.CW exits
in
.CW 8.hi ,
we know that. What happen is that we tried to read the memory address 0x0.
That address is not within any valid memory segment for the process, and reading
.ix "memory segment
it leads to an error (or exception, or fault). That is why the status string contains
.CW "fault read addr=0x0" .
The status string starts with the program name and the process pid, so we
could know which process had a problem. There is more information, the program
counter when the process tried to read 0x0, was 0x000016ff. We do some
post-mortem analysis now.
.PP
The program
.CW src
.ix [src]
.ix "program source
knows how
to obtain the source file name and line number that corresponds to that program counter.
.P1
; src -n -s 0x000016ff 8.hi
/sys/src/libc/fmt/dofmt.c:37
.P2
.LP
We gave the name of the binary file as an argument.
The option
.CW -n
causes the source file name and line to be printed. Otherwise
.CW src
would ask your editor to display that file and line. Option
.CW -s
.ix "symbol
permits you to give a memory address or a symbol name to locate its source.
By the way, this program is an endless source of wisdom. If you want to know how
to implement, say,
.CW cat ,
you can run
.CW "src /bin/cat" .
.PP
Because of the source file name printed, we know that the problem seems to be
within the C library, in
.CW dofmt.c .
What is more likely? Is there a bug in the C library or did we make a mistake
when calling one of its functions? The mystery can be solved by looking at the stack
of the broken process. We can read the process stack because the process is still
there, in the broken state:
.P1
; ps
\fI...many other processes...\fP
nemo 788 0:00 0:00 24K Broken 8.hi
;
.P2
.LP
To print the stack, we call the debugger,
.CW acid :
.ix [acid]
.ix debugging
.ix debugger
.P1
; acid 788
/proc/788/text:386 plan 9 executable
/sys/lib/acid/port
/sys/lib/acid/386
acid:
.P2
.LP
This debugger is indeed a powerful tool, described in [.acid manual.], we will use just
a couple of its functions. After obtaining the prompt
from
.CW acid ,
we ask for a stack dump using the
.CW stk
command:
.ix "[stk] [acid] command
.P1
.ps -2
acid: stk()
dofmt(fmt=0x0,f=0xdfffef08)+0x138 /sys/src/libc/fmt/dofmt.c:37
vfprint(fd=0x1,args=0xdfffef60,fmt=0x0)+0x59 /sys/src/libc/fmt/vfprint.c:30
print(fmt=0x0)+0x24 /sys/src/libc/fmt/print.c:13
main(argv=0xdfffefb4)+0x12 /usr/nemo/9intro/hi.c:8
_main+0x31 /sys/src/libc/386/main9.s:16
acid:
.ps +2
.P2
.LP
The function
.CW stk()
dumps the stack.
The program crashed while executing the function
.CW dofmt ,
at file
.CW dofmt.c .
This function was called by
.CW vfprint ,
which was called by
.CW print ,
which was called by
.CW main .
As you can see, the parameter
.CW fmt
of
.CW print
is zero! That should never happen, because
.CW print
expects its first parameter to be a valid, non-null, string. That was the bug.
.PP
We can gather much more information about this program. For example,
to obtain the values of the local variables in all functions found in the stack
.ix "[lstk] [acid] command
.P1
.ps -2
acid: lstk()
dofmt(fmt=0x0,f=0xdfffef08)+0x138 /sys/src/libc/fmt/dofmt.c:37
nfmt=0x0
rt=0x0
rs=0x0
r=0x0
rune=0x15320000
t=0xdfffee08
s=0xdfffef08
n=0x0
vfprint(fd=0x1,args=0xdfffef60,fmt=0x0)+0x59 /sys/src/libc/fmt/vfprint.c:30
f=0x0
buf=0x0
n=0x0
.ps +2
.P2
.P1
.ps -2
print(fmt=0x0)+0x24 /sys/src/libc/fmt/print.c:13
args=0xdfffef60
main(argv=0xdfffefb4)+0x12 /usr/nemo/9intro/hi.c:8
_main+0x31 /sys/src/libc/386/main9.s:16
.ps +2
.P2
.LP
When your program gets broken, using
.CW lstk()
in
.CW acid
is invaluable. Usually, that is all you need to fix your bug. You have all the
information about what happen from
.CW main
down to the point where it crashed, and you just have to think a little bit
why that could happen. If your program was checking out for errors, things
can be even more easy, because in many case the error diagnostic printed
by the program may suffice to fix up the problem.
.PP
One final note. Can you see how
.CW main
.ix [main]
.ix [_main]
is not the main function in your program? It seems that
.CW _main
in the C library called what we thought was the
.CW main
function.
.PP
The last note about debugging is not about what to do after a program
crashes, but about what to do
.I before .
There is a library function called
.CW abort .
.ix [abort]
This is its code
.P1
void
abort(void)
{
while(*(int*)0)
;
}
.P2
.LP
This function dereferences a nil pointer! You know what would happen to
the miserable program calling
.CW abort .
It gets broken. While you program, it is very sensible to prepare for things
that in theory would not happen. In practice they will happen. One tool
for doing this is
.CW abort .
You can include code that checks for things that should never happen.
Those things that you know in advance that would be very hard to debug.
If your code detects that such things happen, it may call
.CW abort .
The process will enter the broken state for you to debug it before things
.ix [broken]
get worse.
.BS 2 "Everything is a file!
.ix "everything is~a~file
.PP
We have seen two abstractions that are part of the baggage that comes
with processes in Plan 9: Processes themselves and environment variables.
The way to use these abstractions is to perform system calls that operate on
them.
.ix process
.ix "environment variable
.ix "file
.PP
That is nice. But Plan 9 was built considering that it is natural to
have the machine connected to the network. We saw how your files are not
kept at your terminal, but at a remote machine. The designers of the system
noticed that files (another abstraction!) were simple to use. They also
noticed that it was well known how to engineer the system
to permit one machine use files that
were kept at another.
.PP
Here comes the idea! For most abstractions provided by Plan 9, to let you
use your hardware, a
.B "file interface"
is provided. This means that the system
lies to you, and makes you believe that many things, that of course are not,
are files. The point is that they
.I appear
to be files, so that you can use them as if that was really the case.
.PP
The motivation
for doing things this way is that you get simple interfaces to write programs and
use the system, and that you can use also these files from remote machines.
You can debug programs running at a different machine, you can use (almost)
anything from any other computer running Plan 9. All you have to do is to apply
the same tools that you are using to use your real files at your terminal, while
keeping them at a remote machine (the file server).
.PP
Consider the time. Each Plan 9 machine has an idea of what is the time. Internally,
it keeps a counter to notice the time passing by and relies on a hardware clock.
However, for a Plan 9 user, the time seems to be a file:
.ix time
.ix [/dev/time]
.P1
; cat /dev/time
1152301434 1152301434554319872 \fI...\fP
.P2
.LP
Reading
.CW /dev/time
yields a string that contains the time, measured in various forms: Seconds since
the epoch (since a particular agreed-upon point in time in the past), nanoseconds
since the epoch, and clock ticks since the epoch.
.ix "epoch
.PP
Is
.CW /dev/time
a real file? Does it exist in your disk with rest of the files? Of course not!
How can you keep in a disk a file that contains the
.I current
time?
Do you expect a file to change by some black magic so that each different
nanosecond it contains the precise value that matches the current time?
What happens is that when you read the file the system notices you are reading
.CW /dev/time ,
and it knows what to do. To give you the string representing the current system time.
.PP
If this seems confusing, think that files are an abstraction. The system can
decide what reading a file means, and what writing a file means. For real files
sitting on a disk, the meaning is to read and write data from and to the disk
storage. However, for
.CW /dev/time ,
reading means obtaining the string that represents the system time.
Other operating systems provide a
.CW time
system call that returns the time. Plan 9 provides a (fake!) file. The C function
.CW time ,
.ix [time]
described in
.I time (2),
reads this file and returns the integer value that was read.
.PP
Consider now processes. How does
.I ps
know which processes are in the system? Simple. In Plan 9, the
.CW /proc
.ix "[/proc] file system
.ix "[#p] device driver
directory does not exist on disk either. It is a virtual (read: fake) directory
that represents the processes running in the system. Listing the directory
yields one file per process:
.P1
; lc /proc
1 1320 2 246 268 30 32 348
10 135 20 247 269 300 320 367
\fI...\fP
.P2
.LP
But these files are not real files on a disk. They are the
.I interface
for handling running processes in Plan 9.
Each of the files listed above is a directory, and its name is the process pid.
For example, to go to the directory representing the shell we are using we
can do this:
.P1
.ps -2
; echo $pid
938
; cd /proc/938
; lc
args fd kregs note notepg proc regs status wait
ctl fpregs mem noteid ns profile segment text
.ps +2
.P2
.LP
These files provide the interface for the process with pid 938, which was
the shell used. Many of these (fake, virtual) files are provided to permit
debuggers to operate on the process, and to permit programs like
.CW ps
.ix [ps]
gather information about the process. For example, look again at the first
lines printed by
.CW acid
when we broke a process in the last section:
.ix [acid]
.P1
; acid 788
/proc/788/text:386 plan 9 executable
.P2
.LP
Acid is reading
.CW /proc/788/text ,
which
.I "appears to be"
a file containing the binary for the program. The debugger also used
.CW /proc/788/regs ,
to read the values for the processor registers in the process, and
.CW /proc/788/mem ,
.ix "process [mem] file
to read the stack when we asked for a stack dump.
.PP
Besides files intended for debuggers,
other files are for you to use (as long as you remember that they are
not files, but part of the interface for a process). We are now in position of
killing a process. If we write the string
.CW kill
.ix [kill]
.ix "killing a~process
into the file named
.CW ctl ,
.ix [ctl]
.ix "process [ctl] file
we kill the process. For example, this command writes the string
.CW kill
into the
.CW ctl
file of the shell where you execute it. The result is that you are killing the
shell you are using. You are not writing the string
.CW kill
on a disk file. Nobody would record what you wrote to that file.
The more probable result of writing this is that the window where
the shell was running will vanish (because no other processes are using it).
.P1
; echo kill >/proc/$pid/ctl
\fI ... where is my window? ... \fP
.P2
.LP
We saw the memory layout for a process. It had several segments to keep
.ix "memory segment
the process memory. One of the (virtual) files that is part of the process interface
can be used to see which segments a process is using, and where do they start
and terminate:
.P1
; cat /proc/$pid/segment
Stack defff000 dffff000 1
Text R 00001000 00016000 4
Data 00016000 00019000 1
Bss 00019000 0003f000 1
.P2
.LP
.ix "text segment"
.ix "data segment"
.ix "stack segment"
.ix "bss segment"
The stack starts at 0xdefff000, which is a big number. It goes up to
0xdffff000. The process is not probably using all of this stack space. You can see
how the stack segment does
.I not
grow. The physical memory actually used for the process stack will be provided by
the operating system on demand, as it is referenced. Having virtual memory,
there is no need for growing segments.
The text segment is read-only (it has an
.CW R
printed). And four processes are using it! There must be four shells running at
my system,
all of them executing code from
.CW /bin/rc .
.PP
Note how the first few addresses, from 0 to 0x0fff, are not valid. You cannot use
the first 4K of your (virtual) address space. That is how the system catches null
.ix "null pointer
pointer dereferences.
.PP
We have seen most of the file interface provided for processes in Plan 9.
Environment variables are not different. The interface for using environment
.ix "environment variable
variables in Plan 9 is a file interface. To know which environment variables we
have, we can list a (virtual) directory that is invented by Plan 9 to represent
the interface for our environment variables. This directory is
.CW /env .
.ix "[/env] file system
.ix "[#e] device driver
.P1
.SM
; lc /env
'*' cpu init planb sysname
0 cputype location plumbsrv tabstop
MKFILE disk menuitem prompt terminal
afont ether0 monitor rcname timezone
apid facedom mouseport role user
auth 'fn#sigexit' nobootprompt rootdir vgasize
bootdisk font objtype sdC0part wctl
bootfile fs part sdC1part wsys
cflag home partition service
cfs i path status
cmd ifs pid sysaddr
;
.NS
.P2
.LP
Each one of these (fake!) files represents an environment variable. For you and
your programs, these files are as real as those stored in a disk. Because you
can list them, read them, and write them. However, do not search for them
on a disk. They are not there.
.PP
You can see a file named
.CW sysname ,
.ix [sysname]
another named
.CW user ,
.ix [user]
and yet another named
.CW path .
.ix [path]
This means that your shell has the environment variables
.I sysname ,
.I user ,
and
.I path .
Let's double check:
.P1
; echo $user
nemo
; cat /env/user
nemo;
.P2
.LP
The
.I file
.CW /env/user
appears to contain the string
.CW nemo ,
(with no new line at the end). That is precisely the value printed by
.I echo ,
which is the value of the
.I user
environment variable. The implementation of
.I getenv ,
.ix [getenv]
which we used before to return the value of an environment variable, reads
the corresponding file, and returns a C string for the value read.
.PP
This simple idea, representing almost everything as a file, is very powerful. It will
take some ingenuity on your part to fully exploit it. For example, the file
.CW /dev/text
.ix [/dev/text]
.ix "window text
represents the text shown in the window (when used within that window). To
make a copy of your shell session, you already know what to do:
.P1
; cp /dev/text $home/saved
.P2
.LP
The same can be done for the image shown in the display for your window, which is
also represented as a file,
.CW /dev/window .
.ix [/dev/window]
.ix "window image
.ix [rio]
This is what we did to capture screen images for this book.
The same thing works for any program, not just for
.CW cp ,
for example,
.CW lp
.ix [lp]
prints a file, and this command makes a hardcopy of the whole screen.
.ix "screen image
.ix [/dev/screen]
.P1
; lp /dev/screen
.P2
.SH
Problems
.IP 1
Why was not zero the first address used by the memory image of program
.CW global ?
.IP 2
Write a program that defines environment variables for arguments.
For example, after calling the program with options
.P1
; args -ab -d x y z
.P2
.IP
the following must happen:
.P1
; echo $opta
yes
; echo $optb
yes
; echo $optc
yes
; echo $args
x y z
.P2
.IP 3
What would print
.CW "/bin/ls /blahblah"
(given that
.CW /blahblah
does not exits). Would
.CW "ls /blahblah
print the same? Why?
.IP 4
What happens when we execute
.P1
; cd
;
.P2
.IP
after executing this program. Why?
.P1
#include <u.h>
#include <libc.h>
void
main(int, char*[])
{
putenv("home", "/tmp");
exits(nil);
}
.P2
.IP 5
What would do these commands? Why?
.P1
; cd /
; cd ..
; pwd
.P2
.IP 6
After reading
.I date (1),
change the environment variable
.CW timezone
to display the current time in New Jersey (East coast of US).
.IP 7
How can we know the arguments given to a process that has
been already started?
.IP 8
Give another answer for the previous problem.
.IP 9
What could we do if we want to debug a broken process
tomorrow, and want to power off the machine now?
.IP 10
What would happen if you use the debugger,
.CW acid ,
to inspect
.CW 8.out
after executing the next command line? Why?
.P1
; strip 8.out
.P2
.ds CH
.bp