iosys

UNIX v6源代码 这几乎是最经典的unix版本 unix操作系统设计和莱昂氏unix源代码分析都是用的该版

which deal with multiple similar devices
to encode the minor device number.
After the interrupt has been processed,
a return from the interrupt handler will
return from the interrupt itself.
.pg
A number of subroutines are available which are useful
to character device drivers.
Most of these handlers, for example, need a place
to buffer characters in the internal interface
between their ``top half'' (read/write)
and ``bottom half'' (interrupt) routines.
For relatively low data-rate devices, the best mechanism
is the character queue maintained by the
routines
.it getc
and
.it putc.
A queue header has the structure
.pg
.in 5
.ft I
.nf
struct {
	int	c_cc;	/* character count */
	char	*c_cf;	/* first character */
	char	*c_cl;	/* last character */
} queue;
.pg
.ft R
.in 0
.fi
A character is placed on the end of a queue by
.pg
.ti 5
.it "putc(c, &queue)"
.pg
where
.it c
is the character and
.it queue
is the queue header.
The routine returns \(mi1 if there is no space
to put the character, 0 otherwise.
The first character on the queue may be retrieved
by
.pg
.ti 5
.it "getc(&queue)"
.pg
which returns either the (non-negative) character
or \(mi1 if the queue is empty.
.pg
Notice that the space for characters in queues is
shared among all devices in the system
and in the standard system there are only some 600
character slots available.
Thus device handlers,
especially write routines, must take
care to avoid gobbling up excessive numbers of characters.
.pg
The other major help available
to device handlers is the sleep-wakeup mechanism.
The call
.pg
.ti 5
.it "sleep(event, priority)"
.pg
causes the process to wait (allowing other processes to run)
until the
.it event
occurs;
at that time, the process is marked ready-to-run
and the call will return when there is no
process with higher
.it priority.
.pg
The call
.pg
.ti 5
.it "wakeup(event)"
.pg
indicates that the
.it event
has happened, that is, causes processes sleeping
on the event to be awakened.
The
.it event
is an arbitrary quantity agreed upon
by the sleeper and the waker-up.
By convention, it is the address of some data area used
by the driver, which guarantees that events
are unique.
.pg
Processes sleeping on an event should not assume
that the event has really happened;
they should check that the conditions which
caused them to sleep no longer hold.
.pg
Priorities can range from 127 to \(mi127;
a higher numerical value indicates a less-favored
scheduling situation.
A process sleeping at negative priority cannot
be terminated for any reason, although it
is conceivable that it may be swapped out.
Thus it is a bad idea to sleep with negative
priority on an event which might never occur.
On the other hand, calls to
.it sleep
with non-negative priority
may never return if the process is terminated by
some signal in the meantime.
Incidentally, it is a gross error to call
.it sleep
in a routine called at interrupt time, since the process
which is running is almost certainly not the
process which should go to sleep.
Likewise, none of the variables in the user area
``\fIu\fB.\fR''
should be touched, let alone changed, by an interrupt routine.
.pg
If a device driver
wishes to wait for some event for which it is inconvenient
or impossible to supply a
.it wakeup,
(for example, a device going on-line, which does not
generally cause an interrupt),
the call
.pg
.ti 5
.it "sleep(&lbolt, priority)
.pg
may be given.
.it Lbolt
is an external cell whose address is awakened once every 4 seconds
by the clock interrupt routine.
.pg
The routines
.pg
.ti 5
.it "spl4( ), spl5( ), spl6( ), spl7( )"
.pg
are available to
set the processor priority level as indicated to avoid
inconvenient interrupts from the device.
.pg
If a device needs to know about real-time intervals,
then
.pg
.ti 5
.it "timeout(func, arg, interval)
.pg
will be useful.
This routine arranges that after
.it interval
sixtieths of a second, the
.it func
will be called with
.it arg
as argument, in the style
.pg
.ti 5
.it "(*func)(arg)
.pg
Timeouts are used, for example,
to provide real-time delays after function characters
like new-line and tab in typewriter output,
and to terminate an attempt to
read the 201 Dataphone
.it dp
if there is no response within a specified number
of seconds.
Notice that the number of sixtieths of a second is limited to 32767,
since it must appear to be positive,
and that only a bounded number of timeouts
can be going on at once.
Also, the specified
.it func
is called at clock-interrupt time, so it should
conform to the requirements of interrupt routines
in general.
.ms "An example"
The driver for the paper-tape
reader/punch is worth examining
as a fairly simple example of
many of the techniques used in writing
character device handlers.
The
.it pc11
structure contains a state (used for the reader),
an input queue, and an output queue.
A structure, rather than three
individual variables,
was used to cut down on the number of
external symbols which might be confused
with symbols in other routines.
.pg
When the file is opened for reading,
the
.it open
routine checks to see if its state is not
.it CLOSED;
if so an error is returned since it is considered
a bad idea to let several people read one tape
simultaneously.
The state is set to
.it WAITING,
the interrupt is enabled, and a character is requested.
The reason for this gambit is that there is no direct way to
determine if there is any tape in the reader
or if the reader is on-line.
In these situations an interrupt will occur
immediately and an error indicated.
As will be seen, the interrupt routine
ignores errors if the state is
.it WAITING,
but if a good character comes in while
in the
.it WAITING
state the interrupt routine sets the state to
.it READING.
Thus
.it open
loops until the state changes, meanwhile
sleeping on the
``lightning bolt''
.it lbolt.
If it did not sleep at all, it would prevent
any other process from running until the reader came on-line;
if it depended on the interrupt routine to wake it up,
the effect would be the same, since the error
interrupt is almost instantaneous.
.pg
The open-write case is much simpler; the
punch is enabled and a 100-character leader is punched
using
.it pcleader.
.pg
The
.it close
routine is also simple; if the reader was open,
any uncollected characters are flushed,
the interrupt is turned off, and
the state is set to
.it CLOSED.
In the write case a 100-character trailer
is punched.
The routine has a bug in that
if both the reader and punch are open
.it close
will be called only once, so that either the
leftover characters are flushed
or the trailer is punched,
but not both.
It is hard to see how to fix this problem
except by making the reader and punch separate devices.
.pg
The
.it pcread
routine
tries to pick up characters from the input queue
and passes them back until the user's read call
is satisfied.
If there
are no characters it checks
whether the state has gone to
.it EOF,
which means that the interrupt routine
detected an error in the
.it READ
state (assumed to indicate the end of the tape).
If so,
.it pcread
returns;
either during this call or the next one no characters will
be passed back, indicating an end-of-file.
If the state is still
.it READING
the routine enables another character by fiddling the
device's reader control register,
provided it is not active,
and goes to sleep.
.pg
When a reader interrupt occurs
and the state is
.it WAITING,
and the device's error bit is set,
the interrupt is ignored;
if there is no error the state is set to
.it READING,
as indicated in the discussion
of
.it pcread.
If the state is
.it READING
and there is an error, the state is set to
.it EOF;
it is assumed that the error represents
the end of the tape.
If there is no error, the character is picked up and
stored in the input queue.
Then, provided the number of characters
already in the queue is less than the
high-water mark
.it PCIHWAT,
the reader is enabled again to 
read another character.
This strategy keeps the tape moving
without flooding the input queue with unread characters.
Finally, the top half is awakened.
.pg
Looking again at
.it pcread,
notice that
the priority  level is raised
by
.it "spl4( )"
to prevent interrupts during the loop.
This is done because of the
possibility that the input queue is empty,
and just after the EOF test is made
an error interrupt occurs because the
tape runs out.
Then
.it sleep
will be called with no possibility of
a
.it wakeup.
In general the processor priority
should be raised
when a routine is about
to sleep awaiting some condition where the
presence of the condition, and the consequent
.it wakeup,
is indicated by an interrupt.
The danger is that
the interrupt might occur between
the test for the condition and the call to
.it sleep,
so that the
.it wakeup
apparently never happens.
.pg
At the same time it is a bad idea to
raise the processor priority level
for an extended period of time,
since devices with real-time
requirements may be shut out so long as to cause an
error.
The
.it pcread
routine is perhaps overzealous
in this respect, although since most
devices have a priority level higher than 4
this difficulty is not very important.
.pg
The
.it pcwrite
routine simply gets characters from the user
and passes them to
.it pcoutput,
which is separated out so that
.it pcleader
can call it also.
.it Pcoutput
checks for errors (like out-of-tape)
and if none are present
makes sure that
the number of characters in the output queue
does not exceed
.it PCOHWAT;
if it does,
.it sleep
is called.
Then the character is placed on the output queue.
There is a small bug here in that
.it pcoutput
does not check that
the character was successfully put on the queue
(all character-queue space might be empty);
perhaps in this case it might be a good idea to
sleep on the lightning-bolt
until things quiet down.
Finally
.it pcstart
is called,
which checks to see if the punch is currently busy,
and if not starts the punching of the
first character on the output queue.
.pg
When punch interrupts occur,
.it pcpint
is called;
it starts the punching of the next character on the output
queue,
and if the number of characters remaining on the queue is
less than the low-water mark
.it PCOLWAT
it
wakes up the write routine,
which is presumably waiting for the queue to
empty.
.MS "The Block-device Interface"
Handling of block devices is mediated by a collection
of routines which manage a set of buffers containing
the images of blocks of data on the various devices.
The most important purpose of these routines is to assure
that several processes which access the same block of the same
device in multiprogrammed fashion maintain a consistent
view of the data in the block.
A secondary but still important purpose is to increase
the efficiency of the system by
keeping in-core copies of blocks which are being
accessed frequently.
The main data base for this mechanism is the
table of buffers
.it buf.
Each buffer header contains a pair of pointers
.it "(b_forw, b_back)"
which maintain a doubly-linked list
of the buffers associated with a particular
block device, and a
pair of pointers
.it "(av_forw, av_back)"
which generally maintain a doubly-linked list of blocks
which are ``free,'' that is,
eligible to be reallocated for another transaction.
Buffers which have I/O in progress
or are busy for other purposes do not appear in this list.
The buffer header
also contains the device and block number to which the
buffer refers, and a pointer to the actual storage associated with
the buffer.
There is a word count
which is the negative of the number of words
to be transferred to or from the buffer;
there is also an error byte and a residual word
count used to communicate information
from an I/O routine to its caller.
Finally, there is a flag word
with bits indicating the status of the buffer.
These flags will be discussed below.
.pg
Six routines constitute
the most important part of the interface with the
rest of the system.
Given a device and block number,
both
.it bread
and
.it getblk
return a pointer to a buffer header for the block;
the difference is that
.it bread
is guaranteed to return a buffer actually containing the
current data for the block,
while
.it getblk
returns a buffer which contains the data in the
block only if it is already in core (whether it is
or not is indicated by the
.it B_DONE
bit; see below).
In either case the buffer, and the corresponding
device block, is made ``busy,''
so that other processes referring to it
are obliged to wait until it becomes free.
.it Getblk
is used, for example,