iosys

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

.lg
.tr _\(ul
.pl 11i
.ll 6.5i
.ps 10
.vs 11p
.br
.tl '-'''
.de pg
.sp .5
..
.de it
.ft I
\\$1
.ft R
..
.de bd
.ft B
\\$1
.ft R
..
.de he
.tl '-'''
'sp .5i
.ft I
.if e  'tl '% - Unix I/O System'''
.if o 'tl '''Unix I/O System - %'
.ft P
'sp .5i
'ns
..
.de fo
'bp
..
.de MS
.ne 4
.sp
.ft B
\\$1
.pg
.ft R
..
.de ms
.ne 4
.sp
.ft I
\\$1
.pg
.ft R
..
.sp 1.5i
.wh 0 he
.wh -1i fo
.ps 16
.ce
The Unix I/O System
.sp .25i
.ps 10
.ft I
.ce 2
Dennis M. Ritchie
Bell Telephone Laboratories
.ft R
.ps 10
.sp .7i
This paper gives an overview of the workings of the Unix
I/O system.
It was written with an eye toward providing
guidance to writers of device driver routines,
and is oriented more toward describing the environment
and nature of device drivers than the implementation
of that part of the file system which deals with
ordinary files.
.pg
It is assumed that the reader has a good knowledge
of the overall structure of the file system as discussed
in the paper ``The Unix Time-sharing System.''
Moreover the present document is intended to be used in
conjunction with a copy of the system code,
since it is basically an exegesis of that code.
.MS "Device Classes"
There are two classes of device:
.it block
and
.it character.
The block interface is suitable for devices
like disks, tapes, and DECtape
which work, or can work, with addressible 512-byte blocks.
Ordinary magnetic tape just barely fits in this category,
since by use of forward
backward spacing any block can be read, even though
blocks can be written only at the end of the tape.
Block devices can at least potentially contain a mounted
file system.
The interface to block devices is very highly structured;
the drivers for these devices share a great many routines
as well as a pool of buffers.
.pg
Character-type devices have a much
more straightforward interface, although
more work must be done by the driver itself.
.pg
Devices of both types are named by a
.it major
and a
.it minor
device number.
These numbers are generally stored as a word
with the minor device number
as the low byte and the major device number
as the high byte.
The major device number selects which driver will deal with
the device; the minor device number is not used
by the rest of the system but is passed to the
driver at appropriate times.
Typically the minor number
selects a subdevice attached to
a given controller, or one of
several similar hardware interfaces.
.pg
The major device numbers for block and character devices
are used as indices in separate tables;
they both start at 0 and therefore overlap.
.MS "Overview of I/O"
The purpose of
the
.it open
and
.it creat
system calls is to set up entries in three separate
system tables.
The first of these is the
.it u_ofile
table,
which is stored in the system's per-process
data area
.it u.
This table is indexed by
the file descriptor returned by the
.it open
or
.it creat,
and is accessed during
a
.it read,
.it write,
or other operation on the open file.
An entry contains only
a pointer to the corresponding
entry of the
.it file
table,
which is a per-system data base.
There is one entry in the
.it file
table for each
instance of
.it open
or
.it creat.
This table is per-system because the same instance
of an open file must be shared among the several processes
which can result from
.it forks
after the file is opened.
A
.it file
table entry contains
flags which indicate whether the file
was open for reading or writing or is a pipe, and
a count which is used to decide when all processes
using the entry have terminated or closed the file
(so the entry can be abandoned).
There is also a 32-bit file offset
which is used to indicate where in the file the next read
or write will take place.
Finally, there is a pointer to the
entry for the file in the
.it inode
table,
which contains a copy of the file's i-node.
Notice that an entry in the
.it file
table corresponds precisely to an instance of
.it open
or
.it creat;
if the same file is opened several times,
it will have several
entries in this table.
However,
there is at most one entry
in the
.it inode
table for a given file.
Also, a file may enter the
.it inode
table not only because it is open,
but also because it is the current directory
of some process or because it
is a special file containing a currently-mounted
file system.
.pg
An entry in the
.it inode
table differs somewhat from the
corresponding i-node as stored on the disk;
the modified and accessed times are not stored,
and the entry is augmented
by a flag word containing information about the entry,
a count used to determine when it may be
allowed to disappear,
and the device and i-number
whence the entry came.
.pg
During the processing of an
.it open
or
.it creat
call for a special file,
the system always calls the device's
.it open
routine to allow for any special processing
required (rewinding a tape, turning on
the data-terminal-ready lead of a modem, etc.).
However,
the
.it close
routine is called only when the last
process closes a file,
that is, when the i-node table entry
is being deallocated.
Thus it is not feasible
for a device to maintain, or depend on,
a count of its users, although it is quite
possible to
implement an exclusive-use device which cannot
be reopened until it has been closed.
.pg
When a
.it read
or
.it write
takes place,
the user's arguments
and the
.it file
table entry are used to set up the
variables
.it u.u_base,
.it u.u_count,
and
.it u.u_offset
which respectively contain the (user) address
of the I/O target area, the byte-count for the transfer,
and the current location in the file.
If the file referred to is
a character-type special file, the appropriate read
or write routine is called; it is responsible
for transferring data and updating the
count and current location appropriately
as discussed below.
Otherwise, the current location is used to calculate
a logical block number in the file.
If the file is an ordinary file the logical block
number must be mapped (possibly using an indirect block)
to a physical block number; a block-type
special file need not be mapped.
In any event, the resulting physical block number
is used, as discussed below, to
read or write the appropriate device.
.MS "Character device drivers"
The
.it cdevsw
table specifies the interface routines present for
character devices.
Each device provides five routines:
open, close, read, write, and special-function.
Any of these may be missing.
If a call on the routine
should be ignored,
(e.g.
.it open
on non-exclusive devices which require no setup)
the
.it cdevsw
entry can be given as
.it nulldev;
if it should be considered an error,
(e.g.
.it write
on read-only devices)
.it nodev
is used.
.pg
The
.it open
routine is called each time the file
is opened with the full device number as argument.
The second argument is a flag which is
non-zero only if the device is to be written upon.
.pg
The
.it close
routine is called only when the file
is closed for the last time,
that is when the very last process in
which the file is open closes it.
This means it is not possible for the driver to
maintain its own count of its users.
The first argument is the device number;
the second is a flag which is non-zero
if the file was open for writing in the process which
performs the final
.it close.
.pg
When
.it write
is called, it is supplied the device
as argument.
The per-user variable
.it u.u_count
has been set to
the number of characters indicated by the user;
for character devices, this number may be 0
initially.
.it u.u_base
is the address supplied by the user from which to start
taking characters.
The system may call the
routine internally, so the
flag
.it u.u_segflg
is supplied which indicates,
if
.it on,
that
.it u.u_base
refers to the system address space instead of
the user's.
.pg
The
.it write
routine
should copy up to
.it u.u_count
characters from the user's buffer to the device,
decrementing
.it u.u_count
for each character passed.
For most drivers, which work one character at a time,
the routine
.pg
.ti 5
.it "cpass( )"
.pg
is used to pick up characters
from the user's buffer.
Successive calls on it return
the characters to be written until
.it u.u_count
goes to 0 or an error occurs,
when it returns \(mi1.
.it Cpass
takes care of interrogating
.it u.u_segflg
and updating
.it u.u_count.
.pg
Write routines which want to transfer
a probably large number of characters into an internal
buffer may also use the routine
.pg
.ti 5
.it "iomove(buffer, offset, count, flag)"
.pg
which is faster when many characters must be moved.
.it Iomove
transfers up to
.it count
characters into the
.it buffer
starting
.it offset
bytes from the start of the buffer;
.it flag
should be
.it B_WRITE
(which is 0) in the write case.
Caution:
the caller is responsible for making sure
the count is not too large and is non-zero.
As an efficiency note,
.it iomove
is much slower if any of
.it "buffer+offset, count"
or
.it u.u_base
is odd.
.pg
The device's
.it read
routine is called under conditions similar to
.it write,
except that
.it u.u_count
is guaranteed to be non-zero.
To return characters to the user, the routine
.pg
.ti 5
.it "passc(c)"
.pg
is available; it takes care of housekeeping
like
.it cpass
and returns \(mi1 as the last character
specified by
.it u.u_count
is returned to the user;
before that time, 0 is returned.
.it Iomove
is also usable as with
.it write;
the flag should be
.it B_READ
but the same cautions apply.
.pg
The ``special-functions'' routine
is invoked by the
.it stty
and
.it gtty
system calls as follows:
.pg
.ti 5
.it "(*p) (dev, v)"
.pg
where
.it p
is a pointer to the device's routine,
.it dev
is the device number,
and
.it v
is a vector.
In the
.it gtty
case,
the device is supposed to place up to 3 words of status information
into the vector; this will be returned to the caller.
In the
.it stty
case,
.it v
is 0;
the device should take up to 3 words of
control information from
the array
.it "u.u_arg[0...2]."
.pg
Finally, each device should have appropriate interrupt-time
routines.
When an interrupt occurs, it is turned into a C-compatible call
on the devices's interrupt routine.
The interrupt-catching mechanism makes
the low-order four bits of the ``new PS'' word in the
trap vector for the interrupt available
to the interrupt handler.
This is conventionally used by drivers