diff options
Diffstat (limited to 'static/unix-v10/man4')
60 files changed, 5904 insertions, 0 deletions
diff --git a/static/unix-v10/man4/Makefile b/static/unix-v10/man4/Makefile new file mode 100644 index 00000000..38781aad --- /dev/null +++ b/static/unix-v10/man4/Makefile @@ -0,0 +1,3 @@ +MAN = $(wildcard *.4) + +include ../../mandoc.mk diff --git a/static/unix-v10/man4/binarsys.4 b/static/unix-v10/man4/binarsys.4 new file mode 100644 index 00000000..85557191 --- /dev/null +++ b/static/unix-v10/man4/binarsys.4 @@ -0,0 +1,39 @@ +'\"macro stdmacro +.if n .pH g1.binarsys %W% +.nr X +.if \nX=0 .ds x} binarsys 4 "Essential Utilities" "\&" +.if \nX=1 .ds x} binarsys 4 "Essential Utilities" +.if \nX=2 .ds x} binarsys 4 "" "\&" +.if \nX=3 .ds x} binarsys "" "" "\&" +.TH \*(x} +.SH NAME +\f4binarsys\f1 \- remote system information for the \f4ckbinarsys\f1 command +.SH DESCRIPTION +\f4binarsys\f1 +contains lines of the form: +.sp .5 +.ce +\f2remote_system_name\f4:\f2val\f1 +.sp .5 +where \f2val\f1 is either \f4Y\f1 or \f4N\f1. +This line indicates whether that particular remote system can properly +deal with messages having binary content. +The absence of an entry for a particular system +or absence of the \f4binarsys\f1 file altogether will imply \f4N\f1o. +.PP +Blank lines or lines beginning with \f4#\f1 are considered +comments and ignored. +Should a line of \f4Default=y\f1 be encountered, +the default condition for missing entries described in the previous paragraph +is reversed to be \f4Y\f1es. +Another line of \f4Default=n\f1 will restore the default condition to \f4N\f1o. +.PP +\f4mail\f1 is distributed with the \f4binarsys\f1 +file containing only a \f4Default=y\f1 line. +.SH FILES +\f4/etc/mail/binarsys\f1 +.SH SEE ALSO +\f4ckbinarsys\fP(1M), \f4mailsurr\fP(4) +.br +\f4mail\fP(1) in the \f2User's Reference Manual\f1. +.Ee diff --git a/static/unix-v10/man4/bk.4 b/static/unix-v10/man4/bk.4 new file mode 100644 index 00000000..91dec8bc --- /dev/null +++ b/static/unix-v10/man4/bk.4 @@ -0,0 +1,74 @@ +.TH BK 4 +.UC 4 +.SH NAME +bk \- line discipline for machine-machine communication +.SH SYNOPSIS +.B #include <sgtty.h> +.PP +.B int ldisc = NETLDISC, fildes; +\&... +.PP +.B ioctl(fildes, TIOCSETD, &ldisc); +.SH DESCRIPTION +This line discipline provides a replacement for the old and new +tty drivers described in +.IR tty (4) +when high speed output to +and especially input from another machine is to be transmitted +over a asynchronous communications line. The discipline +was designed for use by the Berkeley network +.IR net (1) +but is +well suited to uploading of data from microprocessors into +the system. If you are going to send data over asynchronous +communications lines at high speed into the system, you must +use this discipline, as the system otherwise may detect high +input data rates on terminal lines and disables the lines; +in any case the processing of such data when normal terminal +mechanisms are involved saturates the system. +.PP +A typical application program then reads a sequence of lines from +the terminal port, checking header and sequencing information on each +line and acknowledging receipt of each line to the sender, who then +transmits another line of data. Typically several hundred bytes of +data and a smaller amount of control information will be received on +each handshake. +.PP +The old standard teletype discipline can be restored by doing: +.sp +.ft B +ldisc = OTTYDISC; + +ioctl(fildes, TIOCSETD, &ldisc); +.ft R +.sp +While in networked mode, normal teletype output functions take place. +Thus, if an 8 bit output data path is desired, it is necessary +to prepare the output line by putting it into RAW mode using +.IR ioctl (2). +This must be done +.B before +changing the discipline with TIOCSETD, as most +.IR ioctl (2) +calls are disabled while in network line-discipline mode. +.PP +When in network mode, input processing is very limited to reduce overhead. +Currently the input path is only 7 bits wide, with newline the only +recognized character, terminating an input record. +Each input record must be read and acknowledged before the next input +is read as the system refuses to accept any new data when there +is a record in the buffer. The buffer is limited in length, but the +system guarantees to always be willing to accept input resulting in +512 data characters and then the terminating newline. +.PP +User level programs should provide sequencing and checksums on the +information to guarantee accurate data transfer. +.SH "SEE ALSO" +tty(4) +.SH BUGS +A standard program and protocol should be defined for +uploading data from microprocessors, so that havoc doesn't +result. +.PP +A full 8-bit input path should be provided with a mechanism +for escaping newlines into an input packet. diff --git a/static/unix-v10/man4/bl.4 b/static/unix-v10/man4/bl.4 new file mode 100644 index 00000000..36680e1b --- /dev/null +++ b/static/unix-v10/man4/bl.4 @@ -0,0 +1,41 @@ +.TH BL 4 +.CT 2 file_io file_inq_creat +.SH NAME +bl \- blind directory file system +.SH DESCRIPTION +A directory, blinded by +.IR blmount (8), +is identical in most respects with an ordinary +directory except that it cannot be examined by +.I read +or +.IR stat (2) +and names of newly created entries in the directory are assigned randomly +by the kernel, in response to +.I creat, +.I mknod, +.I mkdir, +.I symlink, +and +.IR link (2) +system calls. +In the case of +.I creat, +if the name requested by the user matches an already existing file +in the directory, the name is not randomized. +The randomized name of a newly created directory entry +may be found with +.IR bcreat ; +see +.IR creat (2). +.LP +Names are randomized in the blind directory only; +names of files properly below the directory are not mangled. +.LP +User processes may put temporary files in a blind directory +to avoid possible violations of security policy by +observing file names. +.SH SEE ALSO +.IR creat (2), +.IR mkunique (3), +.IR blmount (8) diff --git a/static/unix-v10/man4/bufld.4 b/static/unix-v10/man4/bufld.4 new file mode 100644 index 00000000..f9c97d2a --- /dev/null +++ b/static/unix-v10/man4/bufld.4 @@ -0,0 +1,22 @@ +.TH BUFLD 4 +.CT 2 comm_mach +.SH NAME +buf_ld \- buffering line discipline +.SH DESCRIPTION +.I Buf_ld +treasures up data for a while, then emits it in +a burst. +It is otherwise trans\%parent. +It is meant to reduce overhead of programs such as +.IR cu (1) +and +.IR uucp (1) +that read input from moderate-speed lines in raw or cbreak mode. +.PP +It saves characters until +16 have arrived, +or until 1/20 sec has passed +and no more characters have come. +.SH "SEE ALSO +.IR stream (4), +.IR ttyld (4) diff --git a/static/unix-v10/man4/cat.4 b/static/unix-v10/man4/cat.4 new file mode 100644 index 00000000..464fb68c --- /dev/null +++ b/static/unix-v10/man4/cat.4 @@ -0,0 +1,20 @@ +.th CAT IV 10/27/73 +.sh NAME +cat \*- phototypesetter interface +.sh DESCRIPTION +.it Cat +provides the interface to a Graphic Systems C/A/T +phototypesetter. +Bytes written on the file specify font, size, and other control +information as well as the characters to be flashed. +The coding will not be described here. +.s3 +Only one process may have +this file open at a time. +It is write-only. +.sh FILES +/dev/cat +.sh "SEE ALSO" +troff (I), +Graphic Systems specification (available on request) +.sh BUGS diff --git a/static/unix-v10/man4/connld.4 b/static/unix-v10/man4/connld.4 new file mode 100644 index 00000000..babbd7c9 --- /dev/null +++ b/static/unix-v10/man4/connld.4 @@ -0,0 +1,83 @@ +.TH CONNLD 4 +.CT 2 sa comm_proc +.SH NAME +conn_ld \- line discipline for unique stream connection +.SH SYNOPSIS +.B #include <sys/filio.h> +.SH DESCRIPTION +This line discipline +provides unique connections +to a server. +The server process should push the line discipline on a pipe +(see +.B FIOPUSHLD +in +.IR stream (4)) +and +.IR fmount (2) +the pipe end on a file. +A subsequent attempt to +.IR open (2) +or +.IR creat +that file causes a new pipe to be created. +A file descriptor for one +end of the new pipe is passed on the mounted pipe to +to the server process as if by +.BR FIOSNDFD ; +see +.IR stream (4). +The +opening process +is blocked until the server responds. +The server should receive the passed file descriptor with +.RB FIORCVFD +and respond in one of the following ways: +.IP \(em +Accept the new file descriptor by performing +.RS +.IP +.L +ioctl(fd, FIOACCEPT, (void *)0); +.RE +.IP +The originating +.I open +completes and returns a file descriptor for the +other end of the new pipe. +.IP \(em +Write some data on the new file descriptor. +This performs an implicit +.LR FIOACCEPT . +.IP \(em +Pass a different file descriptor: +.RS +.IP +.L +ioctl(fd, FIOSNDFD, &newfd); +.RE +.IP +The originator's end of the new pipe is closed, +and a file descriptor for the open file +designated by +.I newfd +is returned to the originating +.IR open . +.IP \(em +Reject the connection, +by closing the new file descriptor +or by performing +.RS +.IP +.L +ioctl(fd, FIOREJECT, (void *)0); +.RE +.IP +The originating +.I open +fails with +.BR ENXIO +and the new pipe is discarded. +.SH SEE ALSO +.IR fmount (2), +.IR stream (4) diff --git a/static/unix-v10/man4/console.4 b/static/unix-v10/man4/console.4 new file mode 100644 index 00000000..e702bbeb --- /dev/null +++ b/static/unix-v10/man4/console.4 @@ -0,0 +1,63 @@ +.TH CONSOLE 4 +.CT 1 sa_nonmortals +.SH NAME +console \- VAX console interface +.SH DESCRIPTION +.PP +The console terminal is either in +program mode +(connected to the program running in the VAX) +or in console mode +(connected to the console interpreter, +which prompts with +.LR >>> ). +On most VAXes, +.RB control- p +switches to console mode. +If the VAX CPU is still running, +.L "SET TERM PROG" +returns to program mode. +If the CPU is halted, +.L "C" +restarts it +and connects to the VAX. +Hitting the break key +in either mode +may halt the console processor +and produce an +.L @ +prompt; +hit +.L P +to escape. +.PP +On an 11/750, +switching to console mode +always halts the VAX; +only +.L C +will escape. +.RB Control- d +while in console mode +may induce micro-debugging mode, +where the prompt is +.LR RDM> . +Type +.L RET +to return to console mode. +.PP +On a MicroVAX, +the break key (only) halts the VAX and switches to console mode. +.PP +All these modes are implemented by the VAX hardware. +To the operating system, +the console looks like an ordinary terminal +as described in +.IR tty (4), +except that the speed is fixed in the hardware. +.SH FILES +.F /dev/console +.SH "SEE ALSO" +.IR tty (4), +.IR ttyld (4), +.IR reboot (8) diff --git a/static/unix-v10/man4/da.4 b/static/unix-v10/man4/da.4 new file mode 100644 index 00000000..338607ef --- /dev/null +++ b/static/unix-v10/man4/da.4 @@ -0,0 +1,16 @@ +.th DA IV 10/28/73 +.sh NAME +da \*- voice response unit +.sh DESCRIPTION +Bytes written on this file +control a Cognitronics optical drum voice response +unit which +can generate up to 31 fixed half-second utterances. +Bytes read correspond to Touch-Tone\(rg +signals received via a 403 dataset. +.s3 +The specifics of the interface will not be described. +Consult M. E. Lesk for more information. +.sh FILES +/dev/da +.sh BUGS diff --git a/static/unix-v10/man4/dc.4 b/static/unix-v10/man4/dc.4 new file mode 100644 index 00000000..b161f0eb --- /dev/null +++ b/static/unix-v10/man4/dc.4 @@ -0,0 +1,214 @@ +.pa 1 +.he 'DC (IV)'6/12/72'DC (IV)' +.tr | +.ti 0 +NAME dc -- DC-11 communications interfaces +.sp +.ti 0 +DESCRIPTION +.br +.in 8 +The special files +/dev/tty0, /dev/tty1, ... +refer to the +DC11 asynchronous communications interfaces. +At the moment there are ten of them, but the number is subject +to change. + +When one of these files is opened, it causes +the process to wait until a connection is established. +(In practice, however, user's programs seldom open these +files; they are opened by init____ and become a user's standard +input and output file.) +The very first typewriter file open in a process becomes +the control_______ type____writer______ +for that process. The control typewriter plays a special +role in handling quit or interrupt signals, as discussed +below. +The control typewriter is inherited by a child process during a fork____. + +A terminal associated with one of these files ordinarily +operates in full-duplex mode. Characters may be typed at any time, +even while output is occurring, and are only lost when the +system's character input buffers become completely +choked, which is rare, +or when the user has accumulated the maximum allowed number of +input characters which have not yet been read by some program. +Currently this limit is 150 characters. +When this is happening the character "#" is echoed for every lost +input character. + +When first opened, +the interface mode is +ASCII characters; +150 baud; +even parity only accepted; +10 bits/character (one stop bit); +and newline action character. +The system delays transmission after sending certain function characters. +Delays for horizontal tab, newline, and form feed are calculated for +the Teletype Model 37; +the delay for carriage return is calculated for the GE TermiNet|300. +Most of these operating states can be changed +by using the system call stty(II). +In particular +the following hardware states are program settable independently +for input and output (see DC11 manual): +134.5, 150, 300, or 1200 baud; +one or two stop bits on output; +and 5, 6, 7, or 8 data bits/character. +In addition, the following software modes can be invoked: +acceptance of even parity, odd parity, or both; +a raw mode in which all characters may be read one at a time; +a carriage return (CR) mode in which +CR is mapped into newline on input and +either CR or line feed (LF) cause echoing of +the sequence LF-CR; +mapping of upper case letters into lower case; +suppression of echoing; +suppression of delays after function characters; +the printing of tabs as spaces; +and setting the system to handle IBM|2741s. +See getty(VII) for the way that terminal speed and type are +detected. + +Normally, typewriter input is processed in units of lines. +This means that a program attempting +to read will be suspended until an entire line has been +typed. Also, no matter how many characters are requested +in the read call, at most one line will be returned. +It is not however necessary to read a whole line at +once; any number of characters may be +requested in a read, even one, without losing information. + +During input, erase and kill processing is normally +done. +The character "#" erases the +last character typed, except that it will not erase +beyond the beginning of a line or an EOT. +The character "@" kills the entire +line up to the point where it was typed, but not beyond an EOT. Both these +characters operate on a keystroke basis independently +of any backspacing or tabbing that may have been done. +Either "@" or "#" may be entered literally by preceding +it by "\\"; +the erase or kill character remains, but the +"\\" disappears. + +It is possible to use raw mode in which +the program +reading is awakened on each character. +In raw mode, no erase or kill processing is done; +and the EOT, quit and interrupt characters +are not treated specially. + +The ASCII EOT character may be used to generate an end of file +from a typewriter. +When an EOT is received, all the characters +waiting to be read are immediately passed to +the program, without waiting for a new-line. +Thus if there are no characters waiting, which +is to say the EOT occurred at the beginning of a line, +zero characters will be passed back, and this is +the standard end-of-file signal. +The EOT is not passed on except in raw mode. + +When the carrier signal from the dataset drops (usually +because the user has hung up his terminal) any read +returns with an end-of-file indication. +Thus programs which read a typewriter and test for +end-of-file on their input +can terminate appropriately when +hung up on. + +Two characters have a special meaning when typed. +The ASCII DEL character (sometimes called "rubout") +is the interrupt_________ signal. +When this character is received from a given typewriter, +a search is made for all processes which have this typewriter +as their control typewriter, +and which have not informed the system that they wish +to ignore interrupts. +If there is more than one such process, one of these is +selected, for practical purposes at random. +The process is either forced to exit +or a trap is simulated to an agreed-upon location +in the process. +See intr(II). + +The ASCII character FS is the quit____ signal. +Its treatment is identical to the interrupt signal +except that unless the receiving process has +made other arrangements it will not only be terminated +but a core image file will be generated. +See quit(II). +The character is not passed on except in raw mode. + +Output is prosaic compared to input. +When one or more +characters are written, they are actually transmitted +to the terminal as soon as previously-written characters +have finished typing. +Input characters are echoed by putting them in the output queue +as they arrive. +When a process produces characters more rapidly than they can be typed, +it will be suspended when its output queue exceeds some limit. +When the queue has drained down to some threshold +the program is resumed. +Even-parity is always generated on output. +The EOT character is not transmitted to prevent terminals +which respond to it from being hung up. +.sp +The system will handle IBM|2741 terminals. +See getty(VII) for the way that 2741s are detected. +In 2741 mode, +the hardware state +is: +134.5 baud; +one output stop bit; +and 7 bits/character. +Because the 2741 is inherently half-duplex, +input is not echoed. +Proper function delays are provided. +For 2741s without a feature known as "transmit interrupt" +it is not possible to collect input ahead of the time that +a program reads the typewriter, +because once the keyboard has been enabled there is no way +to send further output to the 2741. +It is currently +assumed that the feature is absent; +thus the keyboard is unlocked only when some program reads. +The interrupt signal (normally ASCII DEL) is simulated +when the 2741 "attention" key is pushed to generate either +a 2741 style EOT or a break. +It is not possible to generate anything corresponding to +the end-of-file EOT or the quit signal. +Currently IBM EBCDIC is default for input and output; +correspondence code output is settable (see stty(I)). +.tr || +The full ASCII character set is not available: +"[", "]", "{", "}", "~", are missing on input and are printed as blank on output; +"c|" is used for "\\"; +"_" for "^"; +" " for both "'" and"`"on output; +and " " maps into "'" on input. +.tr | +Similar mappings occur with correspondence code output. +.sp +.in 16 +.ti 0 +FILES /dev/tty[01234567ab] 113B dataphones +.br +/dev/ttyc display data set +.br +/dev/ttyd 113B with /dev/dn1 +.sp +.ti 0 +SEE ALSO kl(IV), getty(VII) +.sp +.ti 0 +BUGS The +primarily Model 37 oriented delays +may not be appropriate +for all other ASCII terminals. +.tr || diff --git a/static/unix-v10/man4/dh.4 b/static/unix-v10/man4/dh.4 new file mode 100644 index 00000000..546367af --- /dev/null +++ b/static/unix-v10/man4/dh.4 @@ -0,0 +1,17 @@ +.TH DH 4 +.UC 4 +.SH NAME +dh \- DH-11 communications multiplexer +.SH DESCRIPTION +Each line attached to the DH-11 communications multiplexer +behaves as described in +.IR tty (4). +Input and output for each line may independently +be set to run at any of 16 speeds; +see +.IR tty (4) +for the encoding. +.SH FILES +/dev/tty[hi][0-9a-f] +.SH "SEE ALSO" +tty(4) diff --git a/static/unix-v10/man4/dispatch.4 b/static/unix-v10/man4/dispatch.4 new file mode 100644 index 00000000..f9b3765a --- /dev/null +++ b/static/unix-v10/man4/dispatch.4 @@ -0,0 +1,32 @@ +.TH DISPATCH 4 "Post 4.0" " " +.SH NAME +dispatch \- post directory configuration file +.SH DESCRIPTION +.I dispatch +files are used by the +.I join +module of +.IR post (1) +to access the directory. +A +.I dispatch +file contains a list of module arguments, one per line. +Argument words are separated by white space. +An open is attempted for each line in turn until one succeeds, or the +end of file is reached, in which case an error is returned. +.P +See +.IR modules (4) +for a description of +.I join +and module arguments. +.SH FILES +.PD 0 +.TP 30 +$POST/lib/dispatch +default configuration file +.PD +.SH SEE ALSO +post(1), +pq(3C), +modules(4). diff --git a/static/unix-v10/man4/dk.4 b/static/unix-v10/man4/dk.4 new file mode 100644 index 00000000..bb51cf57 --- /dev/null +++ b/static/unix-v10/man4/dk.4 @@ -0,0 +1,231 @@ +.TH DK 4 +.CT 2 comm_mach +.SH NAME +dk, dkp_ld, unixp_ld, cmc_ld \- Datakit interface and protocols +.SH SYNOPSIS +.B #include <sys/dkio.h> +.SH DESCRIPTION +These device drivers +and line disciplines +are used to connect to a Datakit network. +Normally the programs in +.IR dkmgr (8) +do all the work. +.PP +Several combinations +of hardware and software +may be used to connect a system to Datakit: +.IP +The +.I dk +driver +works with a +DR11-C +or +DRV11-J +connected through an adapter box +to a Datakit CPM-422. +The host computer does all the protocol work. +.IP +The +.I kdi +driver works with a +KMC11-B +and one of several line units +(KDI, DUBHI, KMS11-P) +connected to one of several Datakit or ISN interface boards. +The KMC11 runs microcode that handles the URP protocol. +.IP +The experimental +.I kmcdk +driver works with a KMC11-B +and a line unit, +as above, +but the KMC11 runs different microcode +implementing a simple DMA engine, +and the host does all the protocol work. +This is slower, +but rather more robust, +than the +.I kdi +setup. +.IP +The experimental +.I cure +driver works with a custom-built microprocessor board +connected to a Datakit, ISN, or Hyperkit +fiber interface. +The host does all the protocol work. +.PP +Each minor device number +represents a Datakit channel; +the device number is the channel number. +The +.I kdi +driver allows only 96 channels per KMC11-line unit pair; +devices 96-191 are channels 0-95 on a second pair, +if present, +and devices 192-255 are channels 0-63 on a third. +For the other drivers, +there may be only one hardware interface, +which may have up to 256 channels. +.PP +.PP +Usually there is one interface, +with files in directory +.FR /dev/dk . +See +.IR dkmgr (8) +for more about naming conventions. +.PP +.I Dkp_ld +is a stream line discipline +implementing the URP protocol. +The +.I kdi +driver makes its own URP arrangements; +other interfaces need the line discipline. +A separate copy of +.I dkp_ld +must be pushed on each active channel. +.PP +.I Cmc_ld +and +.I unixp_ld +are line disciplines set up calls handle and controller handshake messages. +.I Cmc_ld +runs a Research-only call setup protocol; +.I unixp_ld +runs the standard one. +One copy of the appropriate line discipline +must be pushed on the common signaling channel +to deal with occasional controller keep-alive +and maintenance messages. +Other copies of the line discipline +come and go as calls are placed. +.PP +These +.I ioctl +calls are provided by the device drivers: +.nr pI \w'\f5DIOCSTREAM \fP'u +.PD 0 +.TP \n(pIu +.B DIOCNXCL +Allow this channel to be opened many times. +By default, +if a channel is open, +it may not be opened again. +The default is restored +whenever the channel is completely closed. +.TP +.B KIOCSHUT +Reset the +.I kdi +driver, +hanging up all channels. +.PD +.PP +These +.I ioctl +calls are provided by the URP processors, +.I dkp_ld +and +.IR kdi : +.TP \n(pIu +.PD 0 +.B DIOCSTREAM +Don't generate a stream delimiter +when this channel receives a +BOT +trailer. +.TP +.B DIOCRECORD +Insert a stream delimiter after +receiving +BOT; +the default. +.TP +.B DIOCSCTL +The third argument points to a byte; +send that as a Datakit control envelope. +.TP +.B DIOCRCTL +The third argument points to a byte; +copy the most recently received non-URP control envelope there. +Zero means no control +has been received since the last call. +.TP +.B DIOCXWIN +Set transmit window size. +The third argument points to an array of two long integers. +The first number is the maximum size of each URP block; +the second is the number of blocks that may be outstanding. +Blocks may be no more than 4096 bytes, +and the protocol allows no more than eight blocks in a window. +A +.B KIOCINIT +call should follow immediately, +or things may go awry. +.TP +.B KIOCISURP +Return success if +some URP processor +is active on this channel. +.TP +.B KIOCINIT +Initialize URP. +.PD +.PP +These +.I ioctl +calls are provided by the call setup line disciplines: +.TP \n(pIu +.PD 0 +.B DIOCLHN +This is the common signalling channel. +.TP +.B DIOCHUP +Tell the controller to initialize, +hanging up all channels. +.TP +.B DIOCSTOP +Temporarily hold back received data, +so it won't be lost in call setup messages. +.TP +.B DIOCSTART +Release data held by +.BR DIOCSTOP . +.TP +.B DIOCCHAN +The third argument points to an integer; +fill it in with the number +of a free channel for calling out. +This is a hint, not a promise; +the channel may already be taken by the time it is opened. +The caller should be prepared to try again. +.SH FILES +.F /dev/dk +.SH SEE ALSO +.IR dkmgr (8), +.IR kmc (8) +.br +A. G. Fraser and W. T. Marshall, `Data Transport in a +Byte Stream Network', +.I IEEE J-SAC, +(September, 1989) +.br +.I Datakit VSC Internal Interface Specification, +select code 700-283, +AT&T Customer Information Center, Indianapolis +.SH BUGS +.I Dkp_ld +and +.I kdi +insist on using exactly three blocks in a window, +no matter what they are told in +.BR DIOCXWIN . +.br +The +.I kdi +driver has only two block sizes, +28 and 252 bytes. diff --git a/static/unix-v10/man4/dn.4 b/static/unix-v10/man4/dn.4 new file mode 100644 index 00000000..d6ee9f8b --- /dev/null +++ b/static/unix-v10/man4/dn.4 @@ -0,0 +1,35 @@ +.pa 1 +.he 'DN (IV)'3/15/72'DN (IV)' +.ti 0 +NAME dn -- dn-11 ACU interface +.sp +.ti 0 +DESCRIPTION dn?___ +is a write-only file. +Bytes written on dn?___ must be +ASCII as follows: + + 0-9 dial 0-9 + : dial * + ; dial # + = end-of-number + +The entire telephone number must be +presented in a single write_____ system call. + +It is recommended that an end-of-number +code be given even though only one of the +ACU's (113C) actually requires it. +.sp +.ti 0 +FILES /dev/dn0 connected to 801 with dp0 +.br +/dev/dn1 connected to 113C with ttyd +.br +/dev/dn2 not currently connected +.sp +.ti 0 +SEE ALSO dp(IV), dc(IV), write(II) +.sp +.ti 0 +BUGS -- diff --git a/static/unix-v10/man4/dp.4 b/static/unix-v10/man4/dp.4 new file mode 100644 index 00000000..f35898c7 --- /dev/null +++ b/static/unix-v10/man4/dp.4 @@ -0,0 +1,32 @@ +.pa 1 +.he 'DP (IV)'3/15/72'DP (IV)' +.ti 0 +NAME dp -- dp-11 201 data-phone interface +.sp +.ti 0 +DESCRIPTION dp?___ +is a 201 data-phone interface file. +read____ and write_____ calls to dp?___ +are limited to a maximum of 400 bytes. +Each write call is sent as a single record. +Seven bits from each byte +are written along with an eighth odd parity +bit. +The sync must be user supplied. +Each read call returns characters received from a +single record. +Seven bits are returned unaltered; the eighth bit +is set if the byte was not received in odd parity. +A 20 second time out is set and a zero byte +record is returned if nothing is received in that time. +.sp +.ti 0 +FILES /dev/dp0 201 dataphone used to call GCOS +.sp +.ti 0 +SEE ALSO dn(IV), gerts(III) +.sp +.ti 0 +BUGS The dp__ file is +GCOS oriented. +It should be more flexible. diff --git a/static/unix-v10/man4/drum.4 b/static/unix-v10/man4/drum.4 new file mode 100644 index 00000000..fda84c9e --- /dev/null +++ b/static/unix-v10/man4/drum.4 @@ -0,0 +1,16 @@ +.TH DRUM 4 +.CT 2 sa +.SH NAME +drum \- paging device +.SH DESCRIPTION +This file is the paging and swapping device. +It usually refers to an indirect driver +that allows swapping to be spread over several disk drives. +.SH FILES +.F /dev/drum +.SH BUGS +The indirect driver divides the swap area into interleaved sections +of half a megabyte or so; +reads may not span the boundary between sections. +Since the system doesn't allocate blocks across sections, +this probably doesn't matter. diff --git a/static/unix-v10/man4/dz.4 b/static/unix-v10/man4/dz.4 new file mode 100644 index 00000000..7a029174 --- /dev/null +++ b/static/unix-v10/man4/dz.4 @@ -0,0 +1,18 @@ +.TH DZ 4 +.SH NAME +dz \- DZ-11 communications multiplexer +.SH DESCRIPTION +Each line attached to the DZ-11 communications multiplexer +behaves as described in +.IR ttyld (4). +Each line may +be set to run at any of 16 speeds; +see +.IR ttyld (4) +for the encoding. +.SH FILES +/dev/tty# where # is one or two digits +.br +/dev/ttyd[0-9a-f] +.SH "SEE ALSO" +ttyld(4) diff --git a/static/unix-v10/man4/ethernet.4 b/static/unix-v10/man4/ethernet.4 new file mode 100644 index 00000000..f689e664 --- /dev/null +++ b/static/unix-v10/man4/ethernet.4 @@ -0,0 +1,105 @@ +.TH ETHERNET 4 +.CT 2 comm_mach +.SH NAME +ethernet \(mi Ethernet interface +.SH SYNOPSIS +.B #include <sys/enio.h> +.br +.B #include <sys/ethernet.h> +.SH DESCRIPTION +There are drivers for several hardware interfaces to Ethernet. +All have the same programming interface. +.PP +There are eight software channels for each hardware device. +A channel sends and receives packets +for a single Ethernet interface; +hence eight protocols +may be used independently on the same device. +If a channel is open, +it may not be opened again. +.PP +.I Read +and +.I write +deal in Ethernet packets, +consisting of a header +followed by no less than 46 +but no more than 1500 bytes of data. +The header, +defined in +.BR <sys/ethernet.h> , +is as follows: +.LP +.EX +#define ETHERALEN 6 /* bytes in an ethernet address */ + +struct etherpup { + unsigned char dhost[ETHERALEN]; /* destination address */ + unsigned char shost[ETHERALEN]; /* source address */ + unsigned short type; /* protocol type */ +}; +.EE +.LP +The protocol type is in the network's byte order, +most significant byte first. +.PP +.I Read +on a channel returns at most one complete packet. +If only part of a packet fits in the +.I read +buffer, +successive reads return the remainder. +.I Write +should be given a single complete packet; +.B dhost +and +.B type +must be filled in. +The system supplies +.BR shost . +.PP +There are a few +.I ioctl +calls, +defined in +.BR <sys/enio.h> : +.TP "\w'ENIOTYPE 'u" +.B ENIOTYPE +The third argument +points to a short integer; +use that as the protocol type for this channel. +.TP +.B ENIOADDR +The third argument +points to a six-character buffer; +copy the hardware address of this interface there. +.PP +Minor device numbers +0-7 +are the eight channels of the first hardware device +of a given type; +8-15 are the second device, +and so on. +File names usually end in two digits, +like +.B /dev/il13 +for the fourth channel of the second Interlan device. +.SH FILES +.TF /dev/bna?? +.TP +.F /dev/il?? +Interlan NI1010A devices +.TP +.F /dev/qe?? +DEQNA devices +.TP +.F /dev/bna?? +DEBNA devices +.SH SEE ALSO +.IR internet (3), +.IR ipconfig (8) +.SH BUGS +The DEQNA driver +fills in the protocol type field +in transmitted packets; +other drivers don't. diff --git a/static/unix-v10/man4/fd.4 b/static/unix-v10/man4/fd.4 new file mode 100644 index 00000000..29890d84 --- /dev/null +++ b/static/unix-v10/man4/fd.4 @@ -0,0 +1,63 @@ +.TH FD 4 +.CT 2 file_io +.SH NAME +fd, stdin, stdout, stderr, tty \- file descriptor files +.SH DESCRIPTION +These files, conventionally called +.BR /dev/fd/\^0 ", " /dev/fd/1 ", ... " /dev/fd/127 , +refer to files accessible through file descriptors. +If file descriptor +.I n +is open, +these two system calls have the same effect: +.IP +.EX +fd = open("/dev/fd/\fIn\fP", mode); +fd = dup(\fIn\fP\^); +.EE +.LP +On these devices +.I creat +(see +.IR open (2)) +is equivalent to +.I open, +and +.I mode +is ignored. +As with +.IR dup , +subsequent reads or writes on +.I fd +fail unless the original file descriptor +allows the operations. +.SH FILES +.TF /dev/stdout +.TP +.F /dev/fd/* +.TP +.F /dev/stdin +linked to +.F /dev/fd/0 +.TP +.F /dev/stdout +linked to +.F /dev/fd/1 +.TP +.F /dev/stderr +linked to +.F /dev/fd/2 +.TP +.F /dev/tty +linked to +.F /dev/fd/3 +.SH SEE ALSO +.IR open (2), +.IR dup (2) +.SH DIAGNOSTICS +.I Open +returns \-1 +and +.B EBADF +if the related file descriptor is not open +and in the appropriate mode (reading or writing). diff --git a/static/unix-v10/man4/fl.4 b/static/unix-v10/man4/fl.4 new file mode 100644 index 00000000..4bc4e203 --- /dev/null +++ b/static/unix-v10/man4/fl.4 @@ -0,0 +1,24 @@ +.TH FL 4 +.UC 4 +.SH NAME +fl \- floppy interface +.SH DESCRIPTION +.PP +This is a simple interface to the D.E.C. RX01 +floppy disk unit, which is part of the console +LSI-11 subsytem for VAX-11/780's. +Access is given to the entire +floppy consisting of 77 tracks of 26 sectors of 128 bytes. +.PP +All i/o is raw; the seek addresses in raw transfers should be a multiple +of 128 bytes and a multiple of 128 bytes should be transferred. +as in other ``raw'' disk interfaces. +.SH FILES +/dev/floppy +.SH SEE ALSO +arff(8) +.SH BUGS +Multiple console floppies are not supported. +.PP +If a write is given with a count not a multiple of 128 bytes then +the trailing portion of the last sector will be zeroed. diff --git a/static/unix-v10/man4/font.4 b/static/unix-v10/man4/font.4 new file mode 100755 index 00000000..d30767e8 --- /dev/null +++ b/static/unix-v10/man4/font.4 @@ -0,0 +1,59 @@ +.ds ZZ DEVELOPMENT PACKAGE +.TH FONT 4 "630 MTG" +.XE "font" +.SH NAME +font \- font file format +.SH DESCRIPTION +A font file is a file containing a description of a Font that +can be read by +.I infont(3R/3L) +or +.I loadfont(1) +and converted into a Font in the terminal. +A font file can be created by using +.IR outfont . +.PP +A font file begins with a structure that is similar to a Font. +It looks like the following: +.nf + struct Fontheader { + short n; /* number of chars in font */ + char height; /* height of bitmap */ + char ascent; /* top of bitmap to baseline */ + long unused; /* in case we think of more stuff */ + Fontchar info[1]; /* n+1 character descriptors */ + } +.fi + +The fields in this structure have the same meanings as the ones in the +Font structure. There are really +.IR n +1 +Fontchar structures in the info array. The only field that +contains valid data in the [n+1]th element is \f2x\f1; the leftmost +edge of the corresponding cell in the bitmap. +Each Fontchar structure starts on a long integer boundary and is padded with +null characters to the next long integer boundary and the start of the +next Fontchar structure. +Therefore, there are two nulls after each of the +.IR n + 1 +Fontchars in the file. +.PP +Following this in the file is the bitmap image of the font. +This is an array holding the bit image of all the characters +in the font. It corresponds to +.I bits->base +in the Font structure. +Its size is defined as: + + char base[ +.I height +][ +.RI (( info [ +.IR n +1 +].x+31)/32)\(**4 ] + +The last column of bits used by a font is +.IR info [ n +1].x-1. +The width is rounded up to the nearest long integer boundary for the bitmap image. +.SH SEE ALSO +infont(3L), loadfont(1), structures(3R). diff --git a/static/unix-v10/man4/hp.4 b/static/unix-v10/man4/hp.4 new file mode 100644 index 00000000..13c6a774 --- /dev/null +++ b/static/unix-v10/man4/hp.4 @@ -0,0 +1,105 @@ +.TH HP 4 +.UC 4 +.SH NAME +hp \- RP06, RM03, RM-05 moving-head disk +.SH DESCRIPTION +Files with minor device numbers 0 through 7 refer to various portions +of drive 0; +minor devices 8 through 15 refer to drive 1, etc. +.PP +The origin and size of the pseudo-disks on each drive are +as follows: +.PP +.nf +.ta .5i +\w'000000 'u +\w'000000 'u +RP03 partitions + disk start length + 0 0 15884 + 1 15884 33440 + 2 40964 8360 + 3 0 0 + 4 0 0 + 5 0 0 + 6 49324 291346 + 7 0 0 +.PP +.nf +RM03 partitions + disk start length + 0 0 15884 + 1 16000 33440 + 2 0 0 + 3 0 0 + 4 0 0 + 5 0 0 + 6 49600 82080 + 7 0 0 +.PP +.nf +RM05 partitions + disk start length + 0 0 15884 + 1 16416 33440 + 2 0 500992 + 3 341696 15884 + 4 358112 55936 + 5 414048 36944 + 6 341696 159296 + 7 49856 291346 +.fi +.DT +.PP +It is unwise for all of these files to be present in one installation, +since there is overlap in addresses and protection becomes +a sticky matter. +Ordinarily devices 0 and 6 +on rp06 and rm03 drives, +and 0, 7, and either 6 or 5, 6, and 7 on rm05 drives. +Note that the file system sizes are chosen to allow the partitions +to be copied between the rp06's and rm05's. +This is done so that systems with mixed drives +will be able to rearrange file systems easily +(see also +.IR up (4)). +Device 2 is the entire pack, +and is used in pack-to-pack copying. +.PP +The +block +files +access the disk via the system's normal +buffering mechanism +and may be read and written without regard to +physical disk records. +There is also a `raw' interface +which provides for direct transmission between the disk +and the user's read or write buffer. +A single read or write call results in exactly one I/O operation +and therefore raw I/O is considerably more efficient when +many words are transmitted. +The names of the raw files +conventionally +begin with +an extra `r.' +.SH FILES +.ta 2i +/dev/rp[0-3][a-h] block files +.br +/dev/rrp[0-3][a-h] raw files +.SH SEE ALSO +rp(4) +.SH BUGS +In raw I/O +.I read +and +.IR write (2) +truncate file offsets to 512-byte block boundaries, +and +.I write +scribbles on the tail of incomplete blocks. +Thus, +in programs that are likely to access raw devices, +.I read, write +and +.IR lseek (2) +should always deal in 512-byte multiples. diff --git a/static/unix-v10/man4/ht.4 b/static/unix-v10/man4/ht.4 new file mode 100644 index 00000000..e32c880e --- /dev/null +++ b/static/unix-v10/man4/ht.4 @@ -0,0 +1,81 @@ +.TH HT 4 +.UC 4 +.SH NAME +ht \- RH-11/TE-16 magtape interface +.SH DESCRIPTION +The files +.I "mt0, ..., mt15" +refer to the DEC RH/TM/TE-16 magtape. +The files +.I "mt0, ..., mt7" +are 800 bpi, and +.I "mt8, ..., mt15" +are 1600bpi. +The files +.I "mt0, ..., mt3" +and +.I "mt8, ..., mt11" +are rewound when closed; the others are not. +When a file open for writing is closed, a double end-of-file is written. +.PP +A standard tape consists of a +series of 1024 byte records terminated by an +end-of-file. +To the extent possible, the system makes +it possible, if inefficient, to treat +the tape like any other file. +Seeks have their usual meaning and it is possible +to read or write a byte at a time. +Writing in very small units is inadvisable, +however, because it tends to create monstrous record +gaps. +.PP +The +.I mt +files discussed above are useful +when it is desired to access the tape in a way +compatible with ordinary files. +When foreign tapes are to be dealt with, and especially +when long records are to be read or written, the +`raw' interface is appropriate. +The associated files may be named +.I "rmt0, ..., rmt15," +but the same minor-device considerations +as for the regular files still apply. +.PP +Each +.I read +or +.I write +call reads or writes the next record on the tape. +In the write case the record has the same length as the +buffer given. +During a read, the record size is passed +back as the number of bytes read, provided it is no greater +than the buffer size; +if the record is long, an error is indicated. +In raw tape I/O, the buffer must begin on a word boundary +and the count must be even. +Seeks are ignored. +A zero count is returned when a tape mark is read; +another read will fetch the first record of the +next tape file. +.SH FILES +/dev/mt\(**, +/dev/rmt\(** +.SH "SEE ALSO" +tp(1) +.SH BUGS +The magtape system is supposed to be able +to take 64 drives. +Such addressing has never been tried. +These bugs will be fixed when +we get more experience with this device. +.PP +The driver is limited to four transports. +.PP +If any non-data error is encountered, it refuses to do anything +more until closed. +In raw I/O, there should be a way +to perform forward and backward record and file spacing and +to write an EOF mark explicitly. diff --git a/static/unix-v10/man4/intro.4 b/static/unix-v10/man4/intro.4 new file mode 100644 index 00000000..422c296a --- /dev/null +++ b/static/unix-v10/man4/intro.4 @@ -0,0 +1,91 @@ +.TH INTRO 4 +.SH NAME +intro \- introduction to devices, line disciplines, and file systems +.SH DESCRIPTION +This section describes drivers for +devices, +stream line disciplines, +and file systems. +.PP +Devices are accessed through +special files of type +.L S_IFBLK +(block devices) +or +.L S_IFCHR +(character devices); +see +.IR stat (2). +Block devices use a block buffering scheme +within the system, +so that sectored devices like disks +may be accessed a byte at a time. +Character devices don't use the block buffers. +Only block devices may be mounted as disk file systems. +Most block devices +have associated `raw' character devices +that bypass all buffering for fast direct I/O. +.PP +The device associated with a special file is +identified by a pair of numbers: +a major device number +naming the driver, +and a minor device number +picking some particular device or subunit. +Major numbers are listed in +.IR mknod (8). +Minor numbers are specific to each driver; +see the writeups in this section. +Minor numbers are stored in a single unsigned byte; +they are chosen from the range 0-255. +.PP +Some character devices are also +stream devices. +These use a different internal buffering mechanism +to allow data to flow asynchronously. +Various special operations are possible on streams; +see +.IR stream (4). +.PP +Line disciplines are +processing modules that may be inserted into streams. +They are identified by integers +passed to the calls that insert and remove them. +The C library +contains global variables +initialized to the numbers +for various line disciplines; +.IR stream (4) +has a list. +.PP +There are several different types of file system: +conventional disk volumes, +remote file systems +accessed +by the system sending messages though a stream +to a server as described in +.IR netfs (8), +a file system containing a file representing +each process in the system, +and so on. +All of these +appear the same to ordinary processes, +except that not all file systems +implement all operations; +for example, +a process file has a name, +and may be opened, read, and written +like an ordinary file, +but may not be renamed because +.IR proc (4) +doesn't allow that. +.PP +File system types are +identified by integers, +used by and listed in +.IR fmount (2). +They are just magic numbers at present. +.SH SEE ALSO +.IR fmount (2), +.IR stream (4), +.IR mknod (8) diff --git a/static/unix-v10/man4/ip.4 b/static/unix-v10/man4/ip.4 new file mode 100644 index 00000000..62c85c21 --- /dev/null +++ b/static/unix-v10/man4/ip.4 @@ -0,0 +1,261 @@ +.TH IP 4 +.CT 2 comm_mach +.SH NAME +ip, ip_ld \- DARPA internet protocol +.SH SYNOPSIS +.B #include <sys/inio.h> +.br +.B #include <sys/inet/in.h> +.br +.B #include <sys/inet/ip_var.h> +.SH DESCRIPTION +.PP +The +.I ip_ld +line discipline and the +.F /dev/ip* +files together implement the DARPA IP datagram protocol. +They are used by +the programs described in +.IR ipconfig (8) +and +.IR route (8). +.PP +Each Ethernet device, +Datakit channel, +or other stream +that is to send and receive IP packets +must be registered as an +`IP interface' +by pushing +.I ip_ld +and setting local and remote addresses +with +.I ioctl +calls. +Thereafter, +data received from the network +are assumed to be IP packets, +and are intercepted by the line discipline. +Packets destined for the local address of an active IP interface +are routed for reading on one of the +.I ip +device files. +Other packets are routed to the IP interface +with a matching remote address +and retransmitted. +.PP +Data written on +.I ip +devices +are taken to be IP packets, +are handed to the IP interface +with a matching address, +and are sent. +Packets destined for unreachable places +are quietly dropped. +.PP +A packet consists of a single stream record, +followed by a delimiter: +at most one packet is returned by a +.I read +call; +an entire packet must be presented in a single +.IR write . +A packet includes the IP header. +Numbers in the header are in host byte order. +.PP +Different +.I ip +devices handle different protocols atop IP. +The minor device is the protocol number in the IP header; +e.g. 6 for TCP or 17 for UDP. +While an +.I ip +device is open, +it may not be opened again. +IP packets are often processed by pushing a line discipline +such as +.IR tcp_ld +on an +.I ip +device, +rather than by explicit +.I read +and +.I write +calls; +see +.IR tcp (4). +.PP +The following +.IR ioctl (2) +calls, defined in +.BR <sys/inio.h> , +apply to an IP interface. +.B IPIOLOCAL +and either +.B IPIOHOST +or +.B IPIONET +must be called on each interface +before packets will be routed correctly. +Type +.BR in_addr , +defined in +.BR <sys/inet/in.h> , +is a 32-bit integer +representing an IP address +in host byte order. +.nr Pw \w'\f5IPIORESOLVE 'u +.TP \n(Pwu +.B IPIOLOCAL +The third argument points to an +.BR in_addr : +the local IP address for this interface. +.TP +.B IPIOHOST +The third argument points to an +.BR in_addr : +the remote IP address of the single host +reachable through this interface. +.TP +.B IPIONET +The third argument +points to an +.BR in_addr : +the remote IP address of the network of many hosts +reachable through this interface. +IP addresses are matched to the network address +by applying an internal bit-mask: +any IP address for which +.BI ( address & mask )== net-address +is part of the network. +The default mask depends on +the IP address class; +see the IP protocol standard for details. +.TP +.B IPIOMASK +The third argument points to an +.B in_addr +containing a new network mask for this interface. +.TP +.B IPIOMTU +The third argument points to an integer number of bytes. +IP packets larger than this size (1500 by default) +will be split into smaller ones +before being sent through this interface. +.TP +.B IPIOARP +The network device for this interface +is an Ethernet. +Discard the Ethernet header from each incoming packet. +When sending a packet, +prefix an Ethernet header +containing protocol type +.B 0x8 +and a destination address +obtained by looking up the IP destination address +in a table. +If the IP address is not in the table, +discard the packet, +and make an +.B in_addr +containing the offending address +available for reading +on this file descriptor +(the one on which +.I ip_ld +was pushed). +.TP +.B IPIORESOLVE +The third argument points to a structure: +.EX +struct { + in_addr inaddr; + unsigned char enaddr[6]; +}; +.EE +Add an entry to the table consulted after +.BR IPIOARP , +mapping IP address +.B inaddr +to Ethernet address +.BR enaddr . +.LP +The following +.I ioctl +calls, define in +.BR <sys/inio.h> , +apply to the entire IP subsystem; +they may be used on any file with +.I ip_ld +pushed. +.TP \n(Pwu +.B IPIOROUTE +The third argument points to a structure: +.EX +struct route { + in_addr dst; + in_addr gate; +}; +.EE +Arrange that henceforth, +any IP packet destined for address +.B dst +will be routed as if destined for +.BR gate . +.TP +.B IPIOGETIFS +The third argument points to a union as follows. +The structure is defined in +.BR <sys/inet/ip_var.h> . +.EX +union { + int index; + struct ipif { + struct queue *queue; + int flags; + int mtu; + in_addr thishost; + in_addr that; + in_addr mask; + in_addr broadcast; + int ipackets, ierrors; + int opackets, oerrors; + int arp; + int dev; + } ipif; +}; +.EE +Before the call, +.B index +should contain an integer +naming an entry in the system's table +of active interfaces. +Interfaces are numbered in a continuous sequence starting at 0. +Out-of-range numbers return an error. +After the call, +.B ipif +is filled in with various numbers +about that interface. +.SH FILES +.B /dev/ip* +.SH SEE ALSO +.IR ioctl (2), +.IR internet (3), +.IR ipconfig (8), +.IR route (8) +.br +DARPA standards RFC 791, RFC 1122 +.SH BUGS +The ARP mechanism should be generalized +to deal with networks other than Ethernet. +There is only one ARP table for the entire system; +there should be one for each interface. +.br +The structures used by +.B IPIOROUTE +and +.B IPIORESOLVE +should appear in a header file somewhere. diff --git a/static/unix-v10/man4/kl.4 b/static/unix-v10/man4/kl.4 new file mode 100644 index 00000000..1a7dd065 --- /dev/null +++ b/static/unix-v10/man4/kl.4 @@ -0,0 +1,41 @@ +.pa 1 +.he 'KL (IV)'3/15/72'KL (IV)' +.ti 0 +NAME kl -- KL-11/TTY-33 console typewriter +.sp +.ti 0 +DESCRIPTION tty___ +(as distinct from tty?____) +refers to the console +typewriter hard-wired to the PDP-11 via a KL-11 interface. + +Generally, the disciplines involved in dealing with tty___ +are similar to those for tty?____ and section +dc(IV) should be consulted. +The following differences are salient: + +The system calls stty____ and gtty____ do not apply to this +device. +It cannot be placed in raw mode; on input, upper case letters +are always mapped into lower case letters; +a carriage return is echoed when a line-feed is typed. + +The quit character is not FS (as with tty?____) but +is generated by the key labelled "alt mode." + +By appropriate +console switch settings, it is possible to cause +UNIX to +come up as a single-user system +with I/O on this device. +.sp +.ti 0 +FILES /dev/tty +.br +/dev/tty8 synonym for /dev/tty +.sp +.ti 0 +SEE ALSO dc(IV), init(VII) +.sp +.ti 0 +BUGS -- diff --git a/static/unix-v10/man4/log.4 b/static/unix-v10/man4/log.4 new file mode 100644 index 00000000..4616ee38 --- /dev/null +++ b/static/unix-v10/man4/log.4 @@ -0,0 +1,42 @@ +.TH LOG 4 +.CT 2 log_man +.SH NAME +log \- security log file +.SH SYNOPSIS +.B #include <sys/log.h> +.SH DESCRIPTION +The special files +.FR /dev/log/log00 +through +.FR /dev/log/log15 +refer to `repository' files nominated by +.IR syslog (2). +.PP +The kernel automatically records selected events on +the `system log file' +.FR /dev/log/log00 +in the form described in +.IR log (5). +.PP +Any process with write access may write on a log file; +no process has read access. +Each write places in the repository file a +.IR log (5) +record with +.B code += +.BR LOG_USER . +The data written are truncated to +.B LOGLEN +bytes and placed in the +.B body +field. +When logging is not turned on, a log file +acts like a write-only +.BR /dev/null . +.SH FILES +.F /dev/log/* +.SH SEE ALSO +.IR syslog (2), +.IR log (5), +.IR syslog (8) diff --git a/static/unix-v10/man4/lp.4 b/static/unix-v10/man4/lp.4 new file mode 100644 index 00000000..6105cb09 --- /dev/null +++ b/static/unix-v10/man4/lp.4 @@ -0,0 +1,63 @@ +.TH LP 4 +.SH NAME +lp \- line printer +.SH DESCRIPTION +.I Lp +provides the interface to any of the standard +DEC line printers. +When it is opened or closed, a suitable number +of page ejects is generated. +Bytes written are printed. +.PP +An internal parameter within the driver determines +whether or not the device is treated as having +a 96- or 64-character set. +In half-ASCII mode, lower case letters are turned +into +upper case +and certain characters are escaped according to +the following table: +.PP +.br +.ns +.TP 10 +{ +\o"-(" +.br +.ns +.TP 10 +} +\o"-)" +.br +.ns +.TP 10 +\` +\o"-\'" +.br +.ns +.TP 10 +| +\o"\-!" +.br +.ns +.TP 10 +~ +\o"\-^" +.. +.PP +The driver correctly interprets +carriage returns, backspaces, tabs, and form feeds. +A sequence of newlines which extends over the end of +a page is turned into a form feed. +Lines longer than 80 characters are truncated +(This is a parameter in the driver). +Another parameter allows indenting all printout +if it is unpleasantly near the left margin. +.SH FILES +/dev/lp +.SH "SEE ALSO" +lpr(1) +.SH BUGS +Half-ASCII mode, the indent and the maximum line length should +be settable by an +.IR ioctl (2). diff --git a/static/unix-v10/man4/lpr.4 b/static/unix-v10/man4/lpr.4 new file mode 100644 index 00000000..7c9415ef --- /dev/null +++ b/static/unix-v10/man4/lpr.4 @@ -0,0 +1,52 @@ +.pa 1 +.he '6/12/72''LPR (IV)' +.ti 0 +NAME /dev/lpr -- line printer +.sp +.ti 0 +SYNOPSIS -- +.sp +.ti 0 +DESCRIPTION The +line printer special file is +the UNIX interface to a DEC LP-11 line printer. +This file may only be opened (or creat'ed) for writing. +Anything written on this file is printed on the line printer. +The following special cases for the +printer are handled: +.sp +.in +3 +On opening and on closing, the paper is +slewed to the top of the next page. +.sp +For the 64 character printer (LP11-FA), +all lower case letters are +converted to upper case. +.sp +Tabs are converted to align on every eighth column. +.sp +New lines and form feeds are ignored when the +printer is at the top of a page. +This is done so that pr__ and roff____ output may +be directed to the printer and sync on +page boundaries even with automatic page slew. +.sp +Carriage return and back space +can cause multiple printing on a single line +to allow for overstruck graphics. +.sp +.in -3 +.ti 0 +FILES found in /dev +.sp +.ti 0 +SEE ALSO -- +.sp +.ti 0 +DIAGNOSTICS -- +.sp +.ti 0 +BUGS -- +.sp +.ti 0 +OWNER ken, dmr diff --git a/static/unix-v10/man4/mailcnfg.4 b/static/unix-v10/man4/mailcnfg.4 new file mode 100644 index 00000000..046f3d3a --- /dev/null +++ b/static/unix-v10/man4/mailcnfg.4 @@ -0,0 +1,117 @@ +'\"macro stdmacro +.if n .pH g4.mailcnfg %W% of %G% +.nr X +.if \nX=0 .ds x} mailcnfg 4 "Essential Utilities" "\&" +.if \nX=1 .ds x} mailcnfg 4 "Essential Utilities" +.if \nX=2 .ds x} mailcnfg 4 "" "\&" +.if \nX=3 .ds x} mailcnfg "" "" "\&" +.TH \*(x} +.SH NAME +\f4mailcnfg\f1 \- initialization information for \f4mail\fP and \f4rmail\fP +.SH DESCRIPTION +The \f4/etc/mail/mailcnfg\fP file contains initialization information for +the \f4mail\fP and \f4rmail\fP commands. +Each entry in \f4mailcnfg\f1 consists of a line of the form +.P +.RS 20 +\f2Keyword\f4 = \f2Value\f1 +.RE +.P +Leading whitespace, whitespace surrounding the equal sign, and trailing +whitespace is ignored. +\f2Keyword\fP may not contain embedded whitespace, +but whitespace may appear within \f2Value\fP. +Undefined keywords or badly formed entries are silently ignored. +.SS Keyword Definitions +.TP 20 +\f4DEBUG\fP +Takes the same values as the \f4\-x\fP invocation option of \f4mail\fP. +This provides a way of setting a system-wide debug/tracing level. +Typically \f4DEBUG\fP is set to a value of 2, which provides minimal diagnostics +useful for debugging \f4mail\fP and \f4rmail\fP failures. The value of the +\f4\-x\fP \f4mail\fP invocation option will override any specification of +\f4DEBUG\fP in \f4mailcnfg\fP. +.TP 20 +\f4CLUSTER\fP +To identify a closely coupled set of systems by one name to +all other systems, set \f2Value\fP to the cluster name. +This string is used to supply the \f5...remote from...\fP information +on the \f5From\fP header line rather than the system nodename returned by +\f4uname\fP(2). +.TP 20 +\f4FAILSAFE\fP +In the event that the \f4/var/mail\fP directory is accessed via RFS or NFS within +a cluster (see \f4CLUSTER\fP above), +provisions must be made to allow for the directory not being available +when local mail is to be delivered (remote system crash, RFS or NFS problems, +etc.). \f2Value\fP is a string that indicates where to forward the +current message for delivery. Typically this is the remote system +that actually \f2owns\fP \f4/var/mail\fP. In this way, the message is +queued for delivery to that system when it becomes available. +For example, assume a cluster of systems (\f4sysa\fP, \f4sysb\fP, \f4sysc\fP) where +\f4/var/mail\fP is physically mounted on \f4sysc\fP and made available to the +other machines via RFS or NFS. +If \f4sysc\fP were to crash, +the RFS/NFS-accessible \f4/var/mail\fP would become unavailable +and local deliveries of mail would go to \f4/var/mail\fP on the local +system. When \f4/var/mail\fP is re-mounted via RFS/NFS, all messages +deposited in the local directory would be hidden and essentially lost. +To prevent this, if \f4FAILSAFE\fP is defined in \f4mailcnfg\fP, +\f4mail\fP and \f4rmail\fP check for the existence of +\f4/var/mail/:saved\fP, a required subdirectory. +If this subdirectory does not exist, \f4mail\fP assumes that +the RFS/NFS-accessible \f4/var/mail\fP is not available and invokes the +failsafe mechanism of automatically forwarding the message to \f2Value\fP. +In this example \f2Value\fP would be \f4sysc!%n\fP. +The \f4%\f2n\f1 keyword is expanded to be the recipient name +[see \f4mail\fP(1) for details] +and thus the message would be forwarded to \f4sysc\fP!\f2recipient_name\fP. +Because \f4sysc\fP is not available, the message remains on the local system +until \f4sysc\fP is available, and then sent there for delivery. +.TP 20 +\f4DEL_EMPTY_MFILE\fP +If not specified, the default action of \f4mail\fP and \f4rmail\fP is to +delete empty mailfiles if the permissions are 0660 and to retain empty +mailfiles if the permissions are anything else. +If \f2Value\fP is \f4yes\fP, empty mailfiles are always deleted, +regardless of file permissions. +If \f2Value\fP is \f4no\fP, empty mailfiles are never deleted. +.TP 20 +\f4DOMAIN\fP +This string is used to supply the system domain name in place of the +domain name returned by \f4getdomainame\fP(3). +.TP 20 +\f4SMARTERHOST\fP +This string may be set to a smarter host which may be referenced within the +mail surrogate file via \f4%\&X\f1. +.TP 20 +\f4%\f2mailsurr_keyword\f1 +As described in \f4mailsurr\fP(4), certain pre-defined single letter keywords +are textually substituted in surrogate command fields before they are +executed. +While none of the predefined keywords may be changed in meaning, +new ones may be defined to provide a shorthand notation for long strings +(such as \f4/usr/lib/mail/surrcmd\fP) which may appear repeatedly within +the \f4mailsurr\fP file. +Upper case letters are reserved for future use and will be ignored if +encountered here. +.SH FILES +.ft 4 +.nf +/etc/mail/mailcnfg +/etc/mail/mailsurr +/var/mail/:saved +/usr/lib/mail/surrcmd +.fi +.ft 1 +.SH SEE ALSO +\f4mailsurr\fP(4) +.br +\f4mail\fP(1) in the \f2User's Reference Manual\f1 +.br +\f4uname\fP(2), +\f4getdomainame\fP(3) in the \f2Programmer's Reference Manual\f1 +.SH NOTES +If \f4/var/mail\fP is accessed via RFS or NFS and the subdirectory +\f4/var/mail/:saved\fP is not removed from the local system, +the \f4FAILSAFE\fP mechanism will be subverted. diff --git a/static/unix-v10/man4/mailsurr.4 b/static/unix-v10/man4/mailsurr.4 new file mode 100644 index 00000000..2caef904 --- /dev/null +++ b/static/unix-v10/man4/mailsurr.4 @@ -0,0 +1,517 @@ +'\"macro stdmacro +.if n .pH g4.mailsurr %W% of %G% +.\" Emphasis +.de Em +\f2\\$1\fP\\$2 +.. +.nr X +.if \nX=0 .ds x} mailsurr 4 "Essential Utilities" "\&" +.if \nX=1 .ds x} mailsurr 4 "Essential Utilities" +.if \nX=2 .ds x} mailsurr 4 "" "\&" +.if \nX=3 .ds x} mailsurr "" "" "\&" +.TH \*(x} +.SH NAME +\f4mailsurr\f1 \- surrogate commands for routing and transport of mail +.SH DESCRIPTION +The \f4mailsurr\f1 file contains routing and transport surrogate +commands used by the \f4mail\fP command. +Each entry in \f4mailsurr\f1 has three whitespace-separated, +single quote delimited fields: +.P +.RS +.ft 4 +\&'\f2sender\fP' '\f2recipient\fP' '\f2command\fP' +.ft 1 +.RE +.P +or a line that begins +.P +.RS +.ft 4 +Defaults: +.ft 1 +.RE +.P +Entries and fields may span multiple lines, +but leading whitespace on field continuation lines is ignored. +Fields must be less than 1024 characters long after expansion (see +below). +.PP +The sender and recipient fields are regular expressions. +If the sender and recipient fields match those of the message currently +being processed, the associated command is invoked. +.PP +The \f2command\fP field may have one of the following five forms: +.P +.RS +.ft 4 +.nf +\f4A\f1[\f4ccept\f1] +\f4D\f1[\f4eny\f1] +\f4T\f1[\f4ranslate\f1] \f4R=\f1[\f4\(bv\f1]\f2string\f1 +\f4< S=...;C=...;F=...;\f2 command\f1 +\f4>\fP \f2command\f1 +.fi +.ft 1 +.RE +.SS "Regular Expressions" +The sender and recipient fields are composed of regular +expressions (REs) which are digested by the \f4regexp\fP(5) +\f4compile\fP and \f4advance\fP procedures +in the C library. +The regular expressions matched are those from \f4ed\fP(1), with simple +parentheses \f4()\fP playing the role of \f4\e(\e)\fP and the addition of +the \f4+\fP and \f4?\fP operators from \f4egrep\fP(1). +Any single quotes embedded within the REs +.Em must +be escaped by prepending them with a backslash or +the RE is not interpreted properly. +.PP +The \f4mail\fP command prepends a circumflex (\f4^\f1) +to the start and appends a dollar sign (\f4$\f1) to the +end of each RE so that it matches the entire string. +Therefore it would be an error +to use \f4^\f2RE\f4$\f1 in the sender and recipient fields. +To provide case insensitivity, all REs are +converted to lower case before compilation, +and all sender and recipient information is converted to +lower case before comparison. +This conversion is done only for the purposes of RE pattern matching; +the information contained within the +message's header is +.Em not +modified. +.PP +The sub-expression pattern matching capabilities of \f4regexp\fP may be used +in the command field, +that is, \f4(\f1...\f4)\f1, where 1 \(<= \f2n\fP \(<= 9. +Any occurrences of \f4\e\e\f2n\f1 in the +replacement string are themselves replaced by the corresponding \f4(\f1...\f4)\f1 +substring in the matched pattern. +The sub-expression fields from both the sender and recipient fields are +accessible, with the fields numbered 1 to 9 from left to right. +.SS "Accept and Deny Commands" +\f4Accept\fP instructs \f4rmail\fP to continue its processing with the \f4mailsurr\f1 +file, +but to ignore any subsequent matching \f4Deny\fP. +That is, unconditionally accept this message for delivery processing. +\f4Deny\fP instructs \f4rmail\fP to stop processing the \f4mailsurr\f1 file +and to send a negative delivery notification to the originator of the message. +Whichever is encountered first takes precedence. +.SS "Translate Command" +\f4Translate\fP allows optional on-the-fly translation of recipient address +information. +The \f2recipient\fP replacement string is specified as \f4R=\f2string\f1. +.PP +For example, given a command line of the form +.P +.RS 2 +.nf +\f4\&'.+' '([^!]+)@(.+)\e.EUO\e.ATT\e.com' 'Translate R=attmail!\e\e2!\e\e1'\f1 +.fi +.RE +.P +and a recipient address of \f4rob@sysa.EUO.ATT.COM\fP +the resulting recipient address would be \f4attmail!sysa!rob\fP. +.PP +Should the first character after the equal sign be a `\(bv', +the remainder of the string is taken as a command line +to be directly executed by \f4rmail\fP. +If any \f4sh\fP(1) syntax is required +(metacharacters, redirection, etc.), +then the surrogate command must be of the form: +.P +.RS +\f4sh \-c "\f2shell command line...\f4"\f1 +.RE +.P +Special care must be taken to escape properly any embedded back-slashes +and single or double quotes, +since \f4rmail\fP uses double quoting to group +whitespace delimited fields that are meant to be considered as a single +argument to \f4execl\fP(2). +It is assumed that the executed command will write one or more replacement +strings on \f4stdout\fP, one per line. +If more than one line is returned, +each is assumed to be a different recipient for the message. +This mechanism is useful for mailing list expansions. +As stated above, any occurrences of \f4\e\e\f2n\f1 are replaced by the +appropriate substring +.Em before +the command is executed. +If the invoked command does not return at least one replacement string +(no output or just a newline), +the original string is +.Em not +modified. +For example, the command line +.P +.RS +\f4\&'.+' '(.+)' 'Translate R=\(bv/usr/bin/findpath \e\e1'\fP +.RE +.P +allows local routing decisions to be made. +.PP +If the recipient address string is modified, \f4mailsurr\fP +is rescanned from the beginning with the new address(es), +and any prior determination of \f4Accept\fP (see above) is discarded. +.SS "\f4<\fP \f2command\fP" +The intent of a \f4<\fP command is that it is invoked as part of the transport +and delivery mechanism, +with the ready-for-delivery message available to the command +at its standard input. +As such, there are three conditions possible when the command exits: +.RS +.TP 10 +Success +The command successfully delivered the message. +What actually constitutes successful delivery may be different +within the context of different surrogates. +The \f4rmail\fP process assumes that no more processing +is required for the message for the current recipient. +.TP 10 +Continue +The command performed some function +(logging remote message traffic, for example) +but did not do what would be considered message delivery. +The \f4rmail\fP process continues to scan the +\f4mailsurr\f1 file looking for some +other delivery mechanism. +.TP 10 +Failure +The command encountered some catastrophic failure. +The \f4rmail\fP process +stops processing the message and sends to the originator of the message +a non-delivery notification that includes any \f4stdout\fP and \f4stderr\fP +output generated by the command. +.RE +.PP +The semantics of the \f4<\fP command field in the \f4mailsurr\fP file allow +the specification of exit codes that constitute success, continue, and +failure for each surrogate command individually. +The syntax of the exit state specification is: +.P +.RS +.nf +\f4<\f1 WS [\f2exit_state_id\f4=\f2ec\f1[\f4,\f2ec\f1[,...]]\f4;\f1][\f2exit_state_id\f4=\f2ec\f1[,\f2ec\f1[,...]]\f4;\f1 + [...]]] WS\0\f2surrogate_cmd_line\f1 +.fi +.RE +.P +.SM +.I WS +is whitespace. +\f2exit_state_id\fP can have the value \f4S\fP, \f4C\fP, or \f4F\fP. +\f2exit_state_id\fPs can be specified in any order. +\f2ec\fP can +be: +.IP +any integer 0 \(<= \f2n\fP \(<= 255 +[Negative exit values are not possible. +See \f4exit\fP(2) and \f4wait\fP(2).] +.IP +a range of integers of the form \f2lower_limit\f1\-\f2upper_limit\f1 +where the limits are \(>= 0 and \(<= 255, and +.IP +\f4\(**\fP, which implies \f2anything\fP +.PP +For example, a command field of the form: +.P +.RS +\&'\f4< S=1-5,99;C=0,12;F=\(**; \f2command\fP %R'\f1 +.RE +.P +indicates that exit values of 1 through 5, and 99, +are to be considered success, +values of 0 (zero) and 12 indicate continue, +and that anything else implies failure. +If not explicitly supplied, default settings are \f4S=0;C=\(**;\fP. +.PP +It may be possible for ambiguous entries to exist +if two exit states have the same +value, for example, \f4S=12,23;C=\(**;F=23,52\fP; or \f4S=\(**;C=9;F=\(**;\fP. +To account for this, \f4rmail\fP looks for +.Em explicit +exit +values (that is, +.Em not +\&``\(**'') in +order of success, continue, failure. +Not finding an explicit match, +\f4rmail\fP then scans for ``\(**'' in the same order. +.PP +It is possible to eliminate an exit state completely by setting that +state's value to an impossible number. +Since exit values must be between 0 and 255 (inclusive), +a value of 256 is a good one to use. +For example, if you had a surrogate command that was to log all message +traffic, a \f4mailsurr\f1 entry of +.P +.RS 2 +.nf +\f4\&'(.+)'\0'(.+)'\0'\f4<\fPS=256;C=*;\0/usr/lib/mail/surrcmd/logger \e\e1 \e\e2'\f1 +.fi +.RE +.P +would always indicate continue. +.PP +Surrogate commands are executed by \f4rmail\fP directly. +If any shell syntax is required +(metacharacters, redirection, etc.), +then the surrogate command must be of the form: +.P +.RS +\f4sh \-c "\f2shell command line...\f4"\f1 +.RE +.P +Special care must be taken to properly escape any embedded +back-slashes and other characters special to the shell +as stated in the ``Translate'' section above. +.PP +If there are no matching \f4<\fP commands, +or all matching \f4<\fP commands exit with a continue indication, +\f4rmail\fP attempts to deliver the message itself by assuming +that the recipient is local and delivering +the message to \f4/var/mail/\fP\f2recipient\fP. +.SS "\f4>\f1 command" +The intent of a \f4>\fP command is that it is invoked +.Em after +a successful delivery to do any post-delivery processing that may be required. +Matching \f4>\fP commands are executed only if some \f4<\fP command indicates a +successful delivery (see the previous section) +or local delivery processing is successful. +The \f4mailsurr\f1 file is rescanned and +all matching \f4>\fP commands, +not just those following the successful \f4<\fP command, +are executed in order. +The exit status of an \f4>\fP command is ignored. +.SS "Defaults: Line" +The default settings may be redefined by creating a separate +line in the \f4mailsurr\f1 file of the form +.P +.RS +.nf +\f4Defaults: \f1[\f4S=\f1...\f4;\f1][\f4C=\f1...\f4;\f1][\f4F\f1=...\f4;\f1] +.fi +.ft 1 +.RE +.P +\f4Defaults:\fP lines are honored and the indicated default values +redefined when the line is encountered during the normal processing +of the \f4mailsurr\f1 file. +Therefore, to redefine the defaults globally, the \f4Defaults:\fP +line should be the first line in the file. +It is possible to have multiple \f4Defaults:\fP lines in the \f4mailsurr\f1 file, +where each subsequent line overrides the previous one. +.SS "Surrogate Command Keyword Replacement." +Certain special sequences are textually-substituted +in surrogate commands before they are invoked: +.P +.RS +.PD 0 +.TP 11 +\f4%n\f1 +the recipient's full name. +.TP +\f4%R\f1 +the full return path to the originator (useful for sending replies, +delivery failure notifications, etc.) +.TP +\f4%c\f1 +value of the \f5Content-Type:\fP header line if present. +.TP +\f4%C\f1 +\&``\f5text\fP'' or ``\f5binary\fP'', depending on an actual scan of the content. +This is independent of the value of any \f5Content-Type\fP header line encountered +(useful when calling \f4ckbinarsys\fP.) +.TP +\f4%S\f1 +the value of the \f5Subject:\fP header line, if present. +.TP +\f4%l\f1 +value of the \f5Content-Length:\fP header line. +.TP +\f4%L\f1 +the local system name. +This will be either \f4CLUSTER\fP from \f4mailcnfg\fP or the value returned +by \f4uname\fP. +.TP +\f4%U\f1 +the local system name, as returned by \f4uname\fP. +.TP +\f4%X\f1 +the value of \f4SMARTERHOST\fP in \f4mailcnfg\fP. +.TP +\f4%D\f1 +the local domain name. +This will be either \f4DOMAIN\fP from \f4mailcnfg\fP, or the value returned by +\f4getdomainame\fP. +.TP +\f4\e\e\f2n\f1 +as described above, the corresponding (...) +substring in the matched patterns. +This implies that the \f4regexp\fP limitation of 9 substrings is applied +to the sender and recipient REs collectively. +.TP +\f4%\f2keywords\f1 +Other keywords as specified in \f4/etc/mail/mailcnfg\fP. +See \f4mailcnfg\fP(4). +.RE +The sequences \f4%L\fP, \f4%U\fP, \f4%D\fP, and \f4%\f2keywords\f1 are +permitted within the sender and recipient fields as well as in the command +fields. +.PD +.PP +An example of the \f4mailsurr\f1 entry that replaces the +\f4uux\fP ``built-in'' of previous versions of \f4rmail\fP is: +.P +.RS +.nf +\f4\&'.+' '([^@!]+)!(.+)' '< /usr/bin/uux \- \e\e1!rmail (\e\e2)'\fP +.fi +.RE +.SS "Mail Surrogate Examples" +Some examples of mail surrogates include the distribution of message-waiting +notifications to LAN-based recipients and lighting Message-Waiting Lamps, +the ability to mail output to printers, +and the logging of all \f4rmail\fP requests between remote systems +(messages passing through the local system). +The following is a sample \f4mailsurr\f1 file: +.P +.nf +.ft 4 +\s-1# +# Some common remote mail surrogates follow. To activate any +# or all of them, remove the `#' (comment indicators) from +# the beginning of the appropriate lines. Remember that they +# will be tried in the order they are encountered in the file, +# so put preferred surrogates first. + +# Prevent all shell meta-characters +\&'.+' '.*[`;&|^<>()].*' 'Deny' + +# Map all names of the form local-machine!user -> user +\&'.+' '%L!(.+)' 'Translate R=\\1' + +# Map all names of the form uname!user -> user +# Must be turned on when using mail in a cluster environment. +#'.+' '%U!(.+)' 'Translate R=\\1' + +# Map all names of the form user@host -> host!user +\&'.+' '([^!@]+)@(.+)' 'Translate R=\\2!\\1' + +# Map all names of the form host.uucp!user -> host!user +\&'.+' '([^!@]+)\\.uucp!(.+)' 'Translate R=\\1!\\2' + +# Map all names of the form host.local-domain!user -> host!user +# DOMAIN= within /etc/mail/mailcnfg will override getdomainame(3). +\&'.+' '([^!@]+)%D!(.+)' 'Translate R=\\1!\\2' + +# Allow access to `attmail' from remote system `sysa' +\&'sysa!.*' 'attmail!.+' 'Accept' + +# Deny access to `attmail' from all other remotes +\&'.+!.+' 'attmail!.+' 'Deny' + +# Send mail for `laser' to attached laser printer +# Make certain that failures are reported via return mail. +\&'.+' 'laser' '\f4<\fP S=0;F=*; lp \-dlaser' + +# Run all local names through the mail alias processor +# +\&'.+' '[^!@]+' 'Translate R=|/usr/bin/mailalias %n' + +# For remote mail via nusend +#'.+' '([^!]+)!(.+)' '\f4<\fP /usr/bin/nusend \-d \e\e1 \-s \-e \-!"rmail \e\e2" \-' + +# For remote mail via usend +\&'.+' '([^!]+)!(.+)' + '\f4<\fP /usr/bin/usend \-s \-d\e\e1 \-uNoLogin \-!"rmail \e\e2" \- ' + +# For remote mail via uucp +\&'.+' '([^!@]+)!.+' '\f4<\fPS=256;C=0; + /usr/lib/mail/surrcmd/ckbinarsys \-t %C \-s \e\e1' +\&'.+' '([^!@]+)!(.+)' '\f4<\fP /usr/bin/uux \- \e\e1!rmail (\e\e2)' + +# For remote mail via smtp +#'.+' '([^!@]+)!(.+)' '< /usr/lib/mail/surrcmd/smtpqer %R %n' + +# If none of the above work, then let a router change the address. +#'.+' '.*[!@].*' 'Translate R=| /usr/lib/mail/surrcmd/smail -A %n' + +# If none of the above work, then ship remote mail off to a smarter host. +# Make certain that SMARTERHOST= is defined within /etc/mail/mailcnfg. +#'.+' '.*[!@].*' 'Translate R=%X!%n' + +# Log successful message deliveries +\&'(.+)' '(.+)' '\f4>\fP/usr/lib/mail/surrcmd/logger \\1 \\2'\s0 +.ft 1 +.fi +.PP +Note that invoking \f4mail\fP to read mail does not +involve the \f4mailsurr\f1 file or any surrogate processing. +.SS "Security" +Surrogate commands execute +with the permissions of \f4rmail\fP (user \s-1ID\s+1 of the invoker, +group \s-1ID\s+1 of mail). +This allows surrogate commands to validate themselves, +checking that their effective group \s-1ID\s+1 was \f4mail\fP at invocation time. +This requires that all additions to \f4mailsurr\f1 be scrutinized before +insertion to prevent any unauthorized access to users' mail files. +All surrogate commands are executed with the path +\f4/usr/lib/mail/surrcmd:/usr/bin\fP. +.SS "Debugging New \f4mailsurr\f1 Entries" +To debug \f4mailsurr\fP files, +use the \f4\-T\fP option of the \f4mail\fP command. +The \f4\-T\fP option requires an argument that is taken as the +pathname of a test \f4mailsurr\fP file. +If null (as in \f4\-T ""\fP), +the system \f4mailsurr\f1 file is used. +Enter +.P +.RS +.nf +\f4mail\ \-T \f2test_file\0recipient\f1 +.fi +.RE +.P +and some trivial message (like ``\f4testing\fP''), +followed by a line with either just a dot (``\f4.\fP'') or a cntl-D. +The result of using the \f4\-T\fP option is displayed on standard output and +shows the inputs and resulting transformations as \f4mailsurr\f1 is +processed by the \f4mail\fP command for the indicated \f2recipient\fP. +.PP +Mail messages will never be sent or delivered when using the \f4\-T\fP option. +.SH "FILES" +.PD 0 +.TP 27 +\f4/etc/mail/mailsurr\fP +.TP 27 +\f4/usr/lib/mail/surrcmd/\(**\fP +surrogate commands +.TP 27 +\f4/etc/mail/mailcnfg\fP +initialization information for \f4mail\fP +.PD +.SH SEE ALSO +\f4ckbinarsys\fP(1M), +\f4mailcnfg\fP(4) +.br +\f4mail\fP(1), +\f4sh\fP(1), +\f4uux\fP(1), +\f4ed\fP(1), +\f4egrep\fP(1), +in the \f2User's Reference Manual\f1 +.br +\f4exec\fP(2), +\f4exit\fP(2), +\f4wait\fP(2), +\f4popen\fP(3), +\f4regexp\fP(5), +\f4getdomainname\f1(3) +in the \f2Programmer's Reference Manual\f1 +.SH "NOTES" +It would be unwise to install new entries into the system +\f4mailsurr\f1 file without verifying at least their syntactical +correctness via `\f4mail\fP \f4\-\T\fP \f2...\fP' as described above. diff --git a/static/unix-v10/man4/mem.4 b/static/unix-v10/man4/mem.4 new file mode 100644 index 00000000..19425567 --- /dev/null +++ b/static/unix-v10/man4/mem.4 @@ -0,0 +1,34 @@ +.pa 1 +.he 'MEM (IV)'3/15/72'MEM (IV)' +.ti 0 +NAME mem -- core memory +.sp +.ti 0 +DESCRIPTION mem___ +is a special file that is an image of the core memory +of the computer. +It may be used, for example, to examine, +and even to patch the system using the debugger. + +Mem___ is a byte-oriented file; its bytes are numbered +0 to 65,535. + +If a non-existent memory location is +referenced, the user +suffers the resultant bus error. + +Memory referenced through +the file is treated with movb____ instructions. +Certain device registers do not implement +DATOB cycles to odd addresses. +Other registers react strangely to this +addressing. +.sp +.ti 0 +FILES /dev/mem +.sp +.ti 0 +SEE ALSO -- +.sp +.ti 0 +BUGS -- diff --git a/static/unix-v10/man4/mesgld.4 b/static/unix-v10/man4/mesgld.4 new file mode 100644 index 00000000..9a53071f --- /dev/null +++ b/static/unix-v10/man4/mesgld.4 @@ -0,0 +1,168 @@ +.TH MESGLD 4 +.CT 2 comm_mach +.SH NAME +mesg_ld, rmesg_ld \- message line discipline modules +.SH SYNOPSIS +.B #include <sys/types.h> +.br +.B #include <sys/stream.h> +.SH DESCRIPTION +.I Mesg_ld +and +.I rmesg_ld +turn internal stream messages +into ordinary data and vice versa. +They supply a way to splice a stream connection together +through a process or across a network connection. +The messages represent ordinary data +and various control operations. +.PP +After +.IR mesg_ld +has been pushed on a stream, +.IR read (2) +on the stream returns encoded messages; +.I write +is expected to supply messages in the same coding. +An encoded message consists of a header +followed by zero or more bytes of associated data. +The header, +as defined in +.BR <sys/stream.h> , +is of the form +.IP +.EX +struct mesg { + char type; + unsigned char magic; + unsigned char losize, hisize; +}; +#define MSGMAGIC 0345 +#define MSGHLEN 4 /* true length of struct mesg in bytes */ +.EE +.LP +The header is +.B MSGHLEN +bytes long; +beware that this is not always the same as +.LR "sizeof(struct mesg)" . +The +.B magic +field contains the constant +.BR MSGMAGIC , +to help prevent interpreting bad data as a message header. +There are +.B "losize+(hisize<<8)" +bytes of associated data. +.PP +Messages may be written in pieces, +or several messages may be written at once. +At most one message will be read at a time. +If an impossible message is written, +the stream may be shut down. +.PP +.IR Rmesg_ld +is exactly the opposite of +.IR mesg_ld . +It is intended for use with devices +that generate data containing encoded messages. +Here is a list of message types, +defined in +.BR <sys/stream.h> : +.TF M_HANGUP +.TP +.B M_DATA +(0) +Ordinary data. +.TP +.B M_BREAK +(01) +A line break on an RS232-style asynchronous connection. +No associated data. +.TP +.B M_HANGUP +(02) +When received, indicates that the other side has gone away. +Thereafter the stream is useless. +No associated data. +.TP +.B M_DELIM +(03) +A delimiter that introduces a record boundary in the data. +No associated data. +.TP +.B M_IOCTL +(06) +An +.IR ioctl (2) +request. +The associated data is a four-byte integer +containing the +function code, +least significant byte first, +followed by some amount of associated data. +An +.B M_IOCACK +or +.BR M_IOCNAK +reply is expected. +.TP +.B M_DELAY +(07) +A real-time delay. +One byte of data, giving the number of clock ticks of +delay time. +.TP +.B M_CTL +(010) +Device-specific control message. +.TP +.B M_SIGNAL +(0101) +Generate signal number given in the one-byte message. +.TP +.B M_FLUSH +(0102) +Flush input and output queue if possible. +.TP +.B M_STOP +(0103) +Stop transmission immediately. +.TP +.B M_START +(0104) +Restart transmission after +.BR M_STOP . +.TP +.B M_IOCACK +(0105) +Successful reply to +.BR M_IOCTL . +Associated data is to be written back to the caller. +.TP +.B M_IOCNAK +(0106) +Failed reply to +.BR M_IOCTL . +A single-byte message, +if present, +will be returned in +.CW errno +by the failing +.IR ioctl . +.TP +.B M_PRICTL +(0107) +High-priority +device-specific control message. +.PD +.PP +.SH SEE ALSO +.IR stream (4) +.SH BUGS +The format of arguments to +.B M_IOCTL +is machine dependent. +.br +The amount of associated data +is limited, but large (>4K). diff --git a/static/unix-v10/man4/modules.4 b/static/unix-v10/man4/modules.4 new file mode 100644 index 00000000..4863fa16 --- /dev/null +++ b/static/unix-v10/man4/modules.4 @@ -0,0 +1,206 @@ +.TH MODULES 4 "Post 4.0" " " +.SH NAME +Modules, Config \- post directory software configuration +.SH DESCRIPTION +A modules argument describes a particular directory +(database) or network address. +The +.B \-m +option of +.IR post (1) +and +.IR pq (1) +and the arguments to +.IR server (1M) +must describe a directory, +and the +.I pq_open +call of +.IR pq (3C) +can describe either a directory or a network address. +The syntax for modules arguments is described below. +The +.I dirmod +and +.I netmod +arguments below are modules arguments themselves; +in this way various modules can be stacked in a pipeline fashion. +The default modules argument is +.BR "opt join" . +.SS "Directory Modules" +.TP 5 +.BR "tee " "file [dirmod...]" +Attach to the directory specified by +.I dirmod +and save the session in +.I file +in +.IR server (1M) +format. +.TP +.BR "opt " [dirmod...] +Attach to the directory specified by +.I dirmod +and pass directory queries in optimized form. +.TP +.BR "join " [file] +Attach to one or more directories listed in +.I file. +Relative paths are prefixed with $POST. +The default is +.B lib/dispatch +and the format is described in +.IR dispatch (4). +.TP +.BR "virt " [dirmod...] +Attach to the directory specified by +.I dirmod +and translate the virtual attributes +.BR pn , +.BR name , +and +.BR tel +into their constituent attributes (see +.IR post (1)). +.TP +\f3ev\f1 [\f3\-s\f1 sep] [\f3\-d\f1 data] [\f3\-p\f1 proto] [index] +Attach to an +.IR ev (4) +directory: +.I sep +is the field separator (default vertical bar +.RB ( | )), +.I index +is the directory containing the index files (default current directory), +.I data +contains the database records (default +.IB index /Data\f1), +and +.I proto +describes the fields in the data file (default +.IB index /Proto\f1). +Relative paths are prefixed with $POST. +.TP +.BR "call " [netmod...] +Connect to the network address specified by +.I netmod +and use the +.IR server (1M) +protocol. +.SS "Network Modules" +.TP 5 +.BR "tap " "infile outfile [netmod...]" +Connect to the network address specified by +.I netmod +and save the input from the network in +.I infile +and the output to the network in +.I outfile. +.TP +.BR "sys " file +Connect to +.I file +(typically a device) +opened for reading and writing. +.TP +.BR "cmd " "program [args...]" +Connect to the standard input and output of +.I program +run via +.IR execvp (2). +.TP +.BR "dk " dialstring +Connect to the +.IR dk (1) +(Datakit) destination +.I dialstring +(typically +.IR area/exch/line.service ). +.TP +.BR "rx " "host service" +Connect to the +.IR rexec (1) +destination +.I host +and request +.IR service . +.TP +.BR "tcp " "host service" +Connect via the +.IR socket (3) +interface to the TCP/IP +.I host +and request +.IR service . +.TP +.BR "tcpti " "host service" +Connect via the transport interface to the TCP/IP +.I host +and request +.IR service . +.TP +.BR "ti " "netspec address [service]" +Connect to +.I address +on the transport provider +.I netspec +and optionally request +.IR service . +.P +.I Modules +lists the directory and network modules and options +for compiling the directory query system of +.IR post (1). +Each line consists of a module name followed by the +.IR cc (1) +options needed for compilation of that module. +The object file +.IB module .o +is loaded implicitly, and the special module name +.B + +is used to set global compilation options. +Blank lines and comments introduced by sharp +.RB ( # ) +are ignored. +.P +.I Config +reads the +.I Modules +file and creates various files necessary for compilation. +The file +.B config.lib +contains the +.IR cc (1) +options needed to load with programs that use +.IR pq (3C), +and the file +.B networks +lists the network modules that were configured. +Modules are not included if their header files or libraries are not found. +.P +If the environment variable +.B POST +is not set, it defaults to +.B /usr/add-on/post +if it exists, or the home directory of the +.B post +login. +.SH FILES +.PD 0 +.TP 30 +$POST/src/pq/Modules +modules file +.TP +$POST/src/pq/Config +configuration program +.TP +$POST/src/pq/config.lib +libraries needed for compilation +.TP +$POST/lib/networks +configured network modules +.PD +.SH SEE ALSO +post(1), +server(1M), +pq(3C). diff --git a/static/unix-v10/man4/mt.4 b/static/unix-v10/man4/mt.4 new file mode 100644 index 00000000..ca6be2e6 --- /dev/null +++ b/static/unix-v10/man4/mt.4 @@ -0,0 +1,162 @@ +.TH MT 4 +.CT 2 comm_mach +.SH NAME +mt \- magtape interface +.SH SYNOPSIS +.B #include <sys/types.h> +.br +.B #include <sys/mtio.h> +.SH DESCRIPTION +The +.I rmt +files refer to magnetic tape drives. +Filenames beginning with +.L rmt +are rewound when closed; +those beginning with +.L nrmt +are not. +When a file open for writing is closed, two file marks are written. +If the tape is not to be rewound, +it is positioned with the head between the two +file marks. +.PP +Conventionally +.B rmt0 +is 800, +.B rmt1 +is 1600, +and +.B rmt2 +is 6250 bpi. +.PP +Each +.IR read (2) +or +.IR write +call reads or writes the next record on the tape. +.I Read +returns at most a single record; +the return value is the record size. +If the next record is larger than the read buffer, +an error is returned. +A file mark causes +.I read +to return 0; +the next +.I read +will return the next record. +Seeks are ignored. +.PP +An +.IR ioctl (2) +call performs special operations: +.TF MTIOCEEOT +.TP +.B MTIOCTOP +perform a suboperation encoded as below in the +.B mt_op +field of a structure whose address is passed +as the third argument of +.I ioctl. +.IP +.EX +.ta \w'struct 'u +\w'daddr_t 'u +\w'mt_count; 'u +struct mtop { + short mt_op; /* operation */ + daddr_t mt_count; /* repeat count */ +}; +.EE +.PD0 +.RS +.TF MTOFFL +.TP +.B MTWEOF +write an end-of-file record +.TP +.B MTFSF +forward space file +.TP +.B MTBSF +backward space file +.TP +.B MTFSR +forward space record +.TP +.B MTBSR +backward space record +.TP +.B MTREW +rewind +.TP +.B MTOFFL +rewind and put the drive offline +.RE +.PD +.PP +The files described above provide a `raw' interface. +There is also a `block' interface which attempts to treat the tape +like an ordinary file as much as possible. +Block tapes are accessed through files with names beginning with +.L mt +or +.LR nmt . +Such a tape contains a single file, +consisting of a series of 1024-byte records +followed by a file mark. +Seeks have their usual meaning, +and it is possible to read and write a byte at a time, +though writing in very small units may create enormous record gaps. +The file always ends at the most recently written byte. +.PP +Conventions for minor device numbers +vary among different hardware drivers: +.IP "" +For the TU78, +the drive unit number +is encoded in the two low-order bits. +Adding 4 prevents the tape from rewinding at close time. +Adding 8 selects 6250 bpi for writing; +the default is 1600. +The tape drive senses density automatically when reading. +.IP +The TE16 is like the TU78, +except that the default density is 800 bpi, +and adding 8 to the device number selects 1600. +.IP +For TMSCP tape drives such as the TU81 and the TK50, +the unit number is encoded in the three low-order bits. +Adding 128 prevents the tape from rewinding on close. +Density is selected by octal bits 070; +the eight possible values represent +eight different device-dependent tape formats. +For 9-track tape drives, +add 0 for 800 bpi, +8 for 1600, +16 for 6250. +For TK50 cartridge drives, +add 24 (old-style block format). +For TK70 drives, +add 8. +The tape drives sense density automatically on reading, +but if a drive +doesn't support a particular density, +the hardware may complain when the device is opened. +.SH FILES +.F /dev/mt? +.br +.F /dev/rmt? +.br +.F /dev/nmt? +.br +.F /dev/nrmt? +.SH "SEE ALSO" +.IR tape (1) +.SH BUGS +If any non-data error is encountered, +the tape drivers generally refuse to do anything +more until closed. +.br +The naming convention behaves poorly with multiple tape drives. +.br +Block tape has probably outlived its usefulness. diff --git a/static/unix-v10/man4/newtty.4 b/static/unix-v10/man4/newtty.4 new file mode 100644 index 00000000..ce7dacc8 --- /dev/null +++ b/static/unix-v10/man4/newtty.4 @@ -0,0 +1,90 @@ +.TH NEWTTY 4 +.UC 4 +.SH NAME +newtty \- summary of the ``new'' tty driver +.SH SYNOPSIS +.B "stty new" +.PP +.B "stty new crt" +.SH DESCRIPTION +This is a summary of the new tty driver, described completely, with the +old terminal driver, in +.IR tty (4). +The new driver is largely compatible with the old but provides additional +functionality for job control. +.LP +.B "CRTs and printing terminals." +.LP +The new terminal driver acts differently on CRTs and on printing terminals. +On CRTs at speeds of 1200 baud or greater it normally erases input characters +physically with backspace-space-backspace when they are erased logically; +at speed under 1200 baud this is often unreasonably slow, so the cursor +is normally merely moved to the left. This is the behavior when you say +\*(lqstty new crt\*(rq; to have the tty driver always erase the characters say +\*(lqstty new crt crterase crtkill\*(rq, +to have the characters remain even at 1200 +baud or greater say \*(lqstty new crt \-crterase \-crtkill\*(rq. +.LP +On printing terminals the command \*(lqstty new prterase\*(rq should be given. +Logically erased characters are then echoed printed backwards +between a `\e' and an `/' character. +.LP +Other terminal modes are possible, but less commonly used; see +.IR tty (4) +and +.IR stty (1) +for details. +.LP +.B "Input editing and output control." +.PP +When preparing input the character # +(normally changed to ^H using +.IR stty (1)) +erases the last input character, +\&^W the last input word, and the character @ +(often changed to ^U) +erases the entire current input +line. A ^R character causes the pending input to be retyped. +Lines are terminated by a return or a newline; a ^D at the beginning +of a line generates an end-of-file. +.PP +Control characters echo as ^x when typed, for some x; the delete character +is represented as ^?. +.PP +The character ^V may be typed before +.I any +character so that it may be entered without its special effect. +For backwards compatibility with the old tty driver the character `\e' +prevents the special meaning of the character and line erase characters, +much as ^V does. +.LP +Output is suspended when a ^S character is typed and resumed when a ^Q +character is type. Output is discarded after a ^O character is typed +until another ^O is type, more input arrives, or the condition is cleared +by a program (such as the shell just before it prints a prompt.) +.PP +.B "Signals." +.PP +A non-interactive program is interrupted by a ^? (delete); this character +is often reset to ^C using +.IR stty (1). +A quit ^\e character causes programs to terminate like +^? does, but also causes a \fIcore\fR image file to be created which +can then be examined with a debugger. This is often used to stop runaway +processes. +Interactive programs often catch interrupts and return to their command +loop; only the most well debugged programs catch quits. +.PP +Programs may be stopped by hitting ^Z, which returns control to the shell. +They may then be resumed using the job control mechanisms of the shell, +i.e. the +.I fg +(foreground) command. +The character ^Y is like ^Z but takes effect when read rather then when +typed; it is much less frequently used. +.PP +See +.IR tty (4) +for a more complete description of the new terminal driver. +.SH "SEE ALSO" +csh(1), newcsh(1), stty(1), tty(4) diff --git a/static/unix-v10/man4/null.4 b/static/unix-v10/man4/null.4 new file mode 100644 index 00000000..6d308a52 --- /dev/null +++ b/static/unix-v10/man4/null.4 @@ -0,0 +1,14 @@ +.TH NULL 4 +.CT 1 comm_dev +.SH NAME +null \- data sink +.SH DESCRIPTION +Data written on +a null special file +is discarded. +.PP +Reads from +a null special file +always return 0 bytes. +.SH FILES +.F /dev/null diff --git a/static/unix-v10/man4/pc.4 b/static/unix-v10/man4/pc.4 new file mode 100644 index 00000000..461788ea --- /dev/null +++ b/static/unix-v10/man4/pc.4 @@ -0,0 +1,38 @@ +.pa 1 +.he 'PC (IV)'3/15/72'PC (IV)' +.ti 0 +NAME pc -- PC-11 paper tape reader/punch +.sp +.ti 0 +DESCRIPTION ppt___ +refers to the PC-11 paper tape reader or punch, +depending on whether it is read or written. + +When ppt___ is opened for writing, a 100-character leader +is punched. +Thereafter each byte written is punched on +the tape. No editing of the characters +is performed. +When the file is closed, a 100-character trailer is punched. + +When ppt___ is opened for reading, the process +waits until tape is placed in the reader and the reader +is on-line. +Then requests to read cause the characters read +to be passed back to the program, again without +any editing. +This means that several null leader characters +will usually appear at the beginning of the file. +Likewise several nulls are likely to appear at the end. +End-of-file is generated when the tape runs out. + +Seek calls for this file are meaningless. +.sp +.ti 0 +FILES /dev/ppt +.sp +.ti 0 +SEE ALSO -- +.sp +.ti 0 +BUGS -- diff --git a/static/unix-v10/man4/pex.4 b/static/unix-v10/man4/pex.4 new file mode 100644 index 00000000..5b87e11f --- /dev/null +++ b/static/unix-v10/man4/pex.4 @@ -0,0 +1,217 @@ +.TH PEX 4 +.SH NAME +pex \- ioctl requests for process-exclusive access +.SH SYNOPSIS +.nf +.B #include <sys/pex.h> +.PP +.B ioctl(fildes, FIOPX, p) +.B struct pexclude *p; +.PP +.B ioctl(fildes, FIONPX, p) +.B struct pexclude *p; +.PP +.B ioctl(fildes, FIOQX, p) +.B struct pexclude *p; +.PP +.B ioctl(fildes, FIOAPX, p) +.B struct pexclude *p; +.PP +.B ioctl(fildes, FIOANPX, p) +.B struct pexclude *p; +.ig +.PP +.B ioctl(fildes, FIONBUF, np) +.B int *np; +.. +.fi +.SH DESCRIPTION +These +.IR ioctl (2) +requests provide and check temporary exclusive access to +an input/output source. +.B FIOPX +marks as `pexed' the file or +pipe end referred to by +.I fildes. +On a pexed file +.I read, +.IR write (2), +and most forms of +.IR ioctl +work only in the pexing process. +Moreover, these operations do not work in any process +on a half-pexed pipe (a pipe with exactly one pexed end). +The mark remains until the pexing process requests +.B FIONPX +or closes all file descriptors that +refer to the file. +.PP +When +.I fildes +refers to a stream, +.B FIOPX +and +.B FIONPX +require the stream's input and output queues to be empty; +.IR pex (3) +gives a method for emptying them. +When +.I fildes +refers to a pipe, the far end of which is unpexed, +.B FIOPX +waits, with timeout, for an answering +.B FIOPX +or +.B FIONPX +at the far end. +.B FIONPX +waits similarly when the far end is pexed. +Either request returns 1 when it leaves a pipe with exactly one end +pexed. +A pipe must cycle through the fully unpexed state +between fully pexed states; +from the time one end becomes unpexed until the far end does too, +.B FIOPX +on the unpexed end will return error +.BR ECONC . +.PP +If argument +.I p +is nonzero, the structure it points to is filled in +with information about the pexedness of the file and +about the process at the far end of a pexed pipe. +The format, defined in +.BR <sys/filio.h> +is: +.EX +struct pexclude { + int oldnear; /* FIOPX or FIONPX: state at beginning of call */ + int newnear; /* FIOPX or FIONPX: state at end of call */ + int farpid; /* -1 if not pipe, 0 if not pexed, else process id */ + int farcap; /* if farpid>0, capabilities */ + int faruid; /* if farpid>0, user id */ +}; +.EE +Capabilities are represented as in the +.B lb_t +field of a label; see +.IR getflab (2). +.PP +.B FIOQX +obtains the information without affecting state. +.PP +.I Read, write, +or +.I ioctl +calls that fail due to pexedness return error +.BR ECONC . +The only +.I ioctl +requests that may succeed on a half-pexed pipe are +.BR FIOCLEX , +.BR FIONCLEX , +.BR FIOPX , +.BR FIONPX , +and +.BR FIOQX . +A half-pexed pipe is deemed ready by +.IR select (2). +.PP +.B FIOANPX +and +.BR FIOAPX +modify the response of open stream device files to +.B FIOPX +requests. +They require +.B T_EXTERN +capability; see +.IR getplab (2). +After +.B FIOANPX +all +.B FIOPX +requests on the special file return 1 and leave the device in an +unusable state +(as if the device driver were a process at the far end of a pipe, +always responding +.BR FIONPX ). +The treatment is reversed with +.BR FIOAPX . +This mechanism +allows a terminal to be denounced to the kernel +as being +attached to an untrusted remote computer +that cannot guarantee the exclusivity asked by +.BR FIOPX . +.ig +.PP +The request +.B FIONBUF +stores, in the integer pointed to by +.I np, +the number of bytes of data buffers currently in a stream. +This number may exceed the number of bytes of data in +the stream, but a stream will not contain any empty buffers. +The request may be used to tell whether a stream is empty before +executing one of the process-exclusive controls, which +destroy stream contents. +.. +.SH EXAMPLES +A program collecting a password wishes to exclude other +programs from the dialogue. +The following code does the trick. +(When the dialogue passes through +.IR mux (9.1) +or +.IR con (1), +downstream stages of the path to the terminal +can be assumed to be similarly pexed, provided +.B FIOPX +succeeds.) +.IP +.EX +#define ok(p) (p->farpid==-1 || p->farpid>0 && p->farcap!=0) +struct pexclude x; +if(ioctl(fd, FIOPX, &x) == 0 && ok(&x)) { + static char buf[9]; + write(fd, promptstr, strlen(promptstr)); + read(fd, buf, 8); + s = buf; +} else + s = 0; +ioctl(fd, x.oldnear, 0); /* restore state */ +.EE +.LP +An intervening trusted program, with a policy of +recognizing exclusive access only for trusted processes, +may cooperate with +.IP +.EX +n = read(fd, buf, BUFSIZE); +if(n == -1 && errno == ECONC) { + if(ioctl(fd, FIOPX, &pexcode)!=0 || pexcode.farcap==0) + ioctl(fd, FIONPX, 0); + } else /* improper pexing */ +.EE +.SH SEE ALSO +.IR ioctl (2), +.IR pipe (2), +.IR stream (4), +.IR pex (3) +.SH DIAGNOSTICS +.BR EBADF , +.BR ECONC , +.BR EFAULT , +.BR EIO , +.BR ENOTTY +.RB ( FIOAPX +and +.BR FIOANPX ) +.br +.B ECONC +for forbidden IO calls in other processes. +.br +.B EBUSY +for an undrained queue. diff --git a/static/unix-v10/man4/proc.4 b/static/unix-v10/man4/proc.4 new file mode 100644 index 00000000..1d0de279 --- /dev/null +++ b/static/unix-v10/man4/proc.4 @@ -0,0 +1,243 @@ +.TH PROC 4 +.CT 2 proc_man +.SH NAME +proc \- process file system +.SH SYNOPSIS +.B #include <sys/proc.h> +.br +.B #include <sys/pioctl.h> +.SH DESCRIPTION +.I Proc +is a file-system mount point that provides access to the image of each +running process in the system. +The name of each entry in the +.F /proc +directory is a five-digit decimal number corresponding to the process +id. +The owner of each file is the userid of the process; +the group is \-1. +If the process's text file is readable, the owner is granted +read-write permission and the group is granted read permission. +The size of a file is +the total virtual memory size of the process. +The security label is shared with the process, unless the +process has had capability +.B T_NOCHK +(see +.IR getplab (2)) +since last +.IR exec (2), +in which case the lattice value of the label is lattice +top and the privilege fields contain some past value of the +process' privilege fields. +.PP +The standard system-call interface is used to access +.I proc. +.I Open +and +.IR close (2) +behave as usual. +The object process is unaffected, except that setuid bits +will be ignored if it does an +.IR exec (2). +(Setuid bits are also ignored if the +.IR exec "ing" +process has traced signals, or stops on +.IR exec ; +see the description of +.B PIOCSMASK +and +.B PIOCSEXEC +below.) +Data may be transferred +from or to any locations in the object's address space through +.I lseek, +.I read, +and +.IR write (2). +The +.I text segment +begins at virtual address 0; the +.I data segment +starts above the text. +The +.I user area +extends downward below virtual address 0x80000000, and is +.B UPAGES*NBPG +bytes long; the +.I stack segment +grows downward below the user area. +Between the end of the data and +the beginning of the stack lies no-man's land. +The text, data, and stack sizes +may be determined from the process's +.L proc +structure (see below). +There are two differences from reading and writing ordinary files: +(1) no I/O transfer may span a segment boundary; +(2) the user area is writable only in the locations of saved user registers. +.PP +Several process control actions are available through an +.IR ioctl (2) +of the form +.IP +.L +union { struct proc p; long i; } buffer; +.br +.L retval = ioctl(fildes, code, &buffer); +.LP +The possible +.I codes +are as follows: +.TF PIOCSMASK +.TP +.B PIOCGETPR +copies the object's proc structure from the kernel process table +into +.BR buffer.p . +Since this information resides in system space, it is not accessible +via a normal read. +.PD +.TP +.B PIOCSTOP +sends the signal +.B SIGSTOP +to the object, and waits for it to +enter the stopped state. +.TP +.B PIOCWSTOP +simply waits for the object to stop. +.TP +.B PIOCRUN +makes the object runnable again after a stop. +.TP +.B PIOCSMASK +defines (via the bit mask +.BR buffer.i ) +a set of signals to be traced; +i.e., the arrival of such a signal will cause the object to stop. +(The signal numbered +.I n +is specified by the bit +.BI "1<<(" n "-1)\fR.)" +A mask of zeroes turns off the trace. +The traced state and mask bits are inherited by the child of a +.IR fork (2). +When the object is closed, the mask bits are lost, but +the traced state is retained for side effects. +.TP +.B PIOCSEXEC +causes the object to stop after +.IR exec "ing." +This condition is inherited by children and is retained when the +object is closed. +.TP +.B PIOCREXEC +reverses the effect of +.BR PIOCSEXEC . +.TP +.B PIOCCSIG +clears the object's currently pending signal (if any). +.TP +.B PIOCKILL +sends a signal to the process. +.TP +.B PIOCOPENT +provides, in +.BR retval , +a read-only file descriptor +for the object process's text file. +This allows a debugger to find the +symbol table without having to know any path names. +.TP +.B PIOCNICE +increments the object's +.IR nice (2) +priority by the amount +.BR buffer.i . +Only the super user may better a process's priority in this way, but any +user may make the priority worse. +.PP +All system calls are interruptible by signals, so that, for example, +an +.IR alarm (2) +may be set to avoid waiting forever for a process that may never stop. +Any system call is guaranteed to be atomic with respect to the object, +but, as with ordinary files, there is nothing to prevent more than one +process from trying to control the same object. +.PP +The following header files are useful in analyzing +.I proc +files: +.PP +.TF <sys/param.h> +.TP +.B <signal.h> +list of signal numbers +.TP +.B <sys/param.h> +size parameters +.TP +.B <sys/types.h> +special system types +.TP +.B <sys/user.h> +user structure +.TP +.B <sys/proc.h> +proc structure +.TP +.B <sys/reg.h> +locations of saved user registers +.TP +.B <sys/pioctl.h> +ioctl codes +.PD +.SH FILES +.F /proc/* +.SH SEE ALSO +.IR ps (1), +.IR hang (1), +.IR fmount (2), +.IR signal (2), +.IR mount (8), +.IR pi (9.1) +.SH DIAGNOSTICS +This is a list of errors which can occur in addition to the +errors normally associated with the file system; see +.IR intro (2): +.TF ENOENT +.TP +.B ENOENT +is returned if the object process has exited after being opened. +.TP +.B EIO +is returned if I/O is attempted at an illegal address in the object. +.TP +.B EBUSY +is returned if the object is in the midst of changing virtual memory +attributes, or has pages locked for physical I/O. +.TP +.B ENOSPC +is returned if a write is attempted on a shared text segment, but there +is no room on the swap space to make a copy. +.TP +.B EPERM +is returned if someone other than the super user attempts to better +a process's priority by issuing a +.BR PIOCNICE . +.SH BUGS +A process must be swapped in for reading and writing (but not +.IR ioctl ); +this consumes minimal system resources, but may involve a noticeable +delay. +.br +The spectrum of states which result in the +.B EBUSY +error is too conservative. +.br +A process loaded from a text file with magic number 0407 does not have as +a read-only text segment; in this (presumably rare) case +.B PIOCOPENT +does not work, and the process is accessible even if the +text file is read-only. diff --git a/static/unix-v10/man4/ra.4 b/static/unix-v10/man4/ra.4 new file mode 100644 index 00000000..a211ebad --- /dev/null +++ b/static/unix-v10/man4/ra.4 @@ -0,0 +1,218 @@ +.TH RA 4 +.CT 2 sa +.SH NAME +ra \- DEC MSCP disks (RA60, RA80, RA81, RA90) +.SH DESCRIPTION +.I Ra +devices occupy disk drives conforming to +DEC's Mass Storage Control Protocol standard: +drives such as the RA81 +connected via controllers such as the UDA50. +Files with minor device numbers 0 through 7 +refer to different sections of drive 0, +minor devices 8 through 16 refer to drive 1, +and so on up to 63 (8 drives). +.PP +Normally the disk is accessed in 1024-byte blocks (1K). +If 64 is added to the minor device number, +4096-byte blocks (4K) are used instead. +A 4K device mounted as a file system is bitmapped; see +.IR filsys (5). +.PP +Conventionally the files are given names like +.L ra37 +for section 7 of drive 3. +There are no name rules distinguishing 1024-byte files +from 4096-byte files; +in practice the files are almost always the 4096-byte kind. +.PP +The start and size +of the sections of each drive +are as follows. +Sizes are measured in +512-byte hardware sectors. +.PP +.nf +.ta .5i +\w'000000 'u +\w'000000 'u + disk start length + 0 0 10240 + 1 10240 20480 + 2 30720 249848 + 3 280568 249848 + 4 530416 249848 + 5 780264 arbitrarily large + 6 30720 749544 + 7 0 arbitrarily large +.DT +.fi +.PP +The `arbitrarily large' +sections reach to the end of the disk. +.I Rarct +will display disk sizes; see +.IR rarepl (8). +For example, +an RA81 has 891072 sectors, +so section 7 is that size, +and section 5 is +891072\(mi780264=110808 sectors. +An RA90 has 2376153 sectors; +section 7 is that size, +section 5 is +2376153\(mi780264=1595889 sectors. +For other disks, +run +.I rarct +and do the arithmetic. +.PP +The +.I ra +files +discussed above access the disk via the system's normal +buffering mechanism +and may be read and written without regard to +physical disk records. +There is also a `raw' interface +which provides for direct transmission between the disk +and the user's read or write buffer. +A single read or write call results in exactly one I/O operation +and therefore raw I/O is considerably more efficient when +many words are transmitted. +The names of the raw files +begin with +.L rra +and end with a number which selects the same disk +as the corresponding +.L ra +file. +.PP +In raw I/O the buffer must begin on a word boundary, +and counts should be a multiple of 512 bytes +(a disk block). +Likewise +.IR lseek (2) +calls should specify a multiple of 512 bytes. +.PP +Several +.IR ioctl (2) +calls +apply to the raw devices. +.TF UIORRCT +.TP +.B UIOCHAR +The third argument to +.I ioctl +points to an object +to be filled with drive parameters: +.EX +.ta .5i +\w'daddr_t 'u +\w'radsize 'u +struct ud_unit { + daddr_t radsize; /* disk size, sectors */ + daddr_t rctsize; /* RCT size, including pad */ + long medium; /* medium id */ + short tracksz; /* sectors per track */ + short groupsz; /* tracks per group */ + short cylsz; /* groups per cylinder */ + char rbns; /* RBNs per track */ + char copies; /* number of RCT copies */ +}; +.EE +.TF UIORRCT +.TP +.B UIORRCT +The third argument points to an object of type +.EX +struct ud_rctbuf { + caddr_t buf; + int lbn; +}; +.EE +.IP +.B buf +points to a 512-byte buffer, +into which block +.B lbn +of the replacement and caching table +(RCT) +is read. +As many copies of the RCT +as necessary +are examined to find a readable copy +of the block. +.TP +.B UIOWRCT +The third argument is like that of +.BR UIORRCT . +Block +.B lbn +of the RCT is written +in all copies. +.TP +.B UIOREPL +The third argument points to an object of type: +.EX +struct ud_repl { + daddr_t replbn; /* good block */ + daddr_t lbn; /* bad block */ + short prim; /* nonzero if primary replacement */ +}; +.EE +.IP +A `replace' command +is sent to the controller, +requesting that attempts to access logical block +.I lbn +henceforth be revectored to replacement block +.IR replbn . +.I Prim +should be set nonzero +if and only if +.I replbn +is the primary replacement block for +.IR lbn . +.TP +.B UIOSPDW +Arrange that the disk drive will spin down +when the last file using it is closed. +.TP +.B UIORST +Reset the controller +to which this disk is connected. +Any pending operations are abandoned and return an error. +.SH FILES +.F /dev/ra* +.br +.F /dev/rra* +.SH SEE ALSO +.IR rarepl (8) +.br +MSCP Basic Disk Functions Manual +.br +DEC Standard Disk Format Specification +.SH BUGS +In raw I/O +.IR read (2) +and +.IR write +truncate file offsets to 512-byte block boundaries, +and +.I write +scribbles on the tail of incomplete blocks. +Thus, +in programs that are likely to access raw devices, +.I read, write +and +.IR lseek (2) +should always deal in 512-byte multiples. +.PP +.B UIORRCT +and +.B UIOWRCT +will misbehave if invoked on a section +that doesn't start +at the beginning of the disk. +Section 7 +(the whole disk) +is the best choice. +.PP +The 1K/4K flag bit in the device number is unfortunate. diff --git a/static/unix-v10/man4/rf.4 b/static/unix-v10/man4/rf.4 new file mode 100644 index 00000000..134889be --- /dev/null +++ b/static/unix-v10/man4/rf.4 @@ -0,0 +1,37 @@ +.pa 1 +.he 'RF (IV)'3/15/72'RF (IV)' +.ti 0 +NAME rf -- RF11-RS11 fixed-head disk file +.sp +.ti 0 +DESCRIPTION This file refers to the +concatenation of both RS-11 disks. +It may be either read or written, although writing is inherently +very dangerous, since +a file system resides there. + +The disk contains 2048 256-word blocks, +numbered 0 to 2047. +Like the other block-structured devices (TC, RK) +this file is addressed in blocks, not bytes. +This has two consequences: +seek____ calls refer to block numbers, not byte numbers; +and sequential reading or writing always advance the read +or write pointer by at least one block. +Thus successive reads of 10 characters from this file +actually read the first 10 characters from successive +blocks. +.sp +.ti 0 +FILES /dev/rf0 +.sp +.ti 0 +SEE ALSO tc(IV), rk(IV) +.sp +.ti 0 +BUGS The fact that this device +is addressed in terms of blocks, not bytes, is extremely +unfortunate. It is due entirely to the fact that +read and write pointers (and consequently the arguments +to seek____) are single-precision +numbers. diff --git a/static/unix-v10/man4/rk.4 b/static/unix-v10/man4/rk.4 new file mode 100644 index 00000000..5943231d --- /dev/null +++ b/static/unix-v10/man4/rk.4 @@ -0,0 +1,28 @@ +.pa 1 +.he 'RK (IV)'3/15/72'RK (IV)' +.ti 0 +NAME rk -- RK-11/RK03 (or RK05) disk +.sp +.ti 0 +DESCRIPTION rk?___ +refers to an entire RK03 disk as a single sequentially-addressed +file. +Its 256-word blocks are numbered 0 to 4871. +Like the RF disk and the tape files, its +addressing is block-oriented. +Consult the rf(IV) section. +.sp +.ti 0 +FILES /dev/rk0 user available drive +.br +/dev/rk1 /usr file system +.br +/dev/rk2 /sys file system +.br +/dev/rk3 /crp file system +.sp +.ti 0 +SEE ALSO rf(IV), tc(IV) +.sp +.ti 0 +BUGS See rf(IV) diff --git a/static/unix-v10/man4/rp.4 b/static/unix-v10/man4/rp.4 new file mode 100644 index 00000000..8e8a1bfa --- /dev/null +++ b/static/unix-v10/man4/rp.4 @@ -0,0 +1,34 @@ +.pa 1 +.he '6/12/72''RP0 (IV)' +.ti 0 +NAME rp0 -- RP11/RP02 disk +.sp +.ti 0 +SYNOPSIS -- +.sp +.ti 0 +DESCRIPTION rp0___ +refers to the entire RP02 disk as a single sequentially-addressed +file. +Its 256-word blocks are numbered 0 to 40599. +Like the RF disk and the tape files, its +addressing is block-oriented. +Consult the rf0(IV) section. +.sp +.ti 0 +FILES found in /dev +.sp +.ti 0 +SEE ALSO rf0(IV), tap0(IV) +.sp +.ti 0 +DIAGNOSTICS -- +.sp +.ti 0 +BUGS See rf0(IV) +.br +Due to a hardware bug, +block 40599 on the RP cannot be accessed. +.sp +.ti 0 +OWNER ken, dmr diff --git a/static/unix-v10/man4/rv.4 b/static/unix-v10/man4/rv.4 new file mode 100644 index 00000000..9351ece9 --- /dev/null +++ b/static/unix-v10/man4/rv.4 @@ -0,0 +1,71 @@ +.TH RV 4 +.SH NAME +rv \- Racal/Vadic ACU interface +.SH DESCRIPTION +The racal/vadic ACU interface is provided by the files +.I /dev/cua[01] +which is a multiplexed file, and by the daemon +.I dnd +which monitors the file, simulating a standard DN dialer. +To place an outgoing call one forks a sub-process +trying to open +.I /dev/cul? +and then opens the corresponding file +.I /dev/cua? +file and writes a number on it. +The daemon translates the call to proper format for the +Racal/Vadic interface, and monitors the progress of the call +recording accounting information for later use. +.PP +The codes for the phone numbers are the same as in the DN interface: +.TP +0-9 +dial 0-9 +.br +.ns +.TP +.B : +dial * +.br +.ns +.TP +.B ; +dial # +.br +.ns +.TP +\- +delay for second dial tone +.br +.ns +.TP +< +end-of-number +.PP +The entire telephone number must be +presented in a single +.I write +system call. +.PP +It is require that an end-of-number +code be given. +.DT +.SH FILES +/dev/cua0 virtual dialer for 300 baud dialout +.br +/dev/cua1 virtual dialer for 1200 baud dialout +.br +/dev/cul0 the terminal which is connected to the 300 baud dialout +.br +/dev/cul1 the terminal which is connected to the 1200 baud dialout +.br +/usr/adm/dnacct Accounting records for sucessfully completed calls. +.SH "SEE ALSO" +cu(1), uucp(1) +.SH BUGS +Locking problems. +.PP +The multiplexor seems to have rare-case bugs which occasinally crash +the system taking trap type 9's, usually in the +.I sdata +system routine. diff --git a/static/unix-v10/man4/scsi.4 b/static/unix-v10/man4/scsi.4 new file mode 100644 index 00000000..19da9039 --- /dev/null +++ b/static/unix-v10/man4/scsi.4 @@ -0,0 +1,117 @@ +.TH SCSI 4 +.CT 2 sa +.SH NAME +scsi \- SCSI interface +.SH SYNOPSIS +.B "#include <scsi.h>" +.SH DESCRIPTION +The special file +.F /dev/scsi +provides a low level interface to a SCSI bus. +Commands are transmitted to the bus by +.IR write ; +the response to each command is received with +.IR read (2). +The format of a command is +.IP +.EX +.ta \w'unsigned char scsistatus; 'u +unsigned long tran_id; /* transaction id */ +unsigned char target; /* SCSI id of target device */ +unsigned char flags; /* flags for this transaction */ +char cmd[10]; /* SCSI command */ +char data[]; /* optional data */ +.EE +.LP +Thus, to send +.I n +bytes of data, the byte count for +.I write +should be +.IR n +16. +Possible flags are +.B SCSI_WR +(data goes from host to SCSI), +.B SCSI_RD +(data goes from SCSI to host), +.B SCSI_BRESET +(reset the SCSI bus), +.B SCSI_RESET +(reset the controller), +and +.B SCSI_SENSE +(return extended sense data on error). +For most controllers, +.B SCSI_BRESET +implies +.BR SCSI_RESET . +Flags are OR'ed together, and there must be exactly one of +.B SCSI_WR +and +.BR SCSI_RD . +.LP +The data read is structured as +.IP +.EX +unsigned long tran_id; /* transaction id */ +unsigned char status; /* scsi status byte */ +unsigned char message; /* scsi message byte */ +unsigned char flags; /* flags for this transaction */ +unsigned char c_type; /* 1=td 2=us */ +unsigned short c_reg1; /* td=sa, us=csr */ +unsigned short c_reg2; /* td=mscp, us=per */ +unsigned char sense[22]; /* extended sense data */ +char data[]; /* any data */ +.EE +.LP +Thus, to read +.I n +bytes of data. the byte count to +.I read +should be +.IR n +34. +If +.I flags +has the +.B SCSI_CERR +bit set, +there was a controller error, which is described by the +.B c_ +fields. +The values of +.B csr +(or +.BR sa ) +and +.B per +(or +.BR mscp ) +are documented in the interface manual for the U.S. Design 1158 +Unibus controller (or T.D. Systems Viking controller). +If the +.B SCSI_SENSE +bit was set in the +.I write, +and the status byte shows a check condition, +an attempt is made to get extended sense information. +If the attempt succeeds the +.B SCSI_SENSE +is set in +.I flags. +Otherwise, the status and message bytes for the failed +attempt are placed in +.B sense[0] +and +.B sense[1] +respectively. +.PP +The transaction id identifies which +.I write +caused the results for this +.IR read . +This will become more important when multiple simultaneous transactions +are allowed. +.SH FILES +.F /dev/scsi +.SH "SEE ALSO" +.IR scsish (8) diff --git a/static/unix-v10/man4/stream.4 b/static/unix-v10/man4/stream.4 new file mode 100644 index 00000000..24fd2c06 --- /dev/null +++ b/static/unix-v10/man4/stream.4 @@ -0,0 +1,272 @@ +.TH STREAM 4 +.CT 2 comm_proc +.SH NAME +stream \- I/O control for streams +.SH SYNOPSIS +.B #include <sys/filio.h> +.br +.B #include <sys/ttyio.h> +.PP +.B ioctl(fd, code, param) +.br +.B void *param; +.SH DESCRIPTION +A stream is a connection between two processes, or between a process +and a device. +It is referred to by a file descriptor, and ordinary read and write +calls apply. +When a +.IR write (2) +call is given on a stream whose other end has disappeared, +for example because the process at other end of a pipe has terminated, +or a device has hung up, signal +.B SIGPIPE +is generated; if the signal is ignored, +the write call returns error +.BR EPIPE . +The first several (currently 64) +.IR read (2) +calls on such a disconnected streams +return 0; +subsequent calls generate +.B SIGPIPE +signals. +.PP +Processing modules may be inserted into streams. +These +.IR ioctl (2) +calls insert, delete, inspect, and perform operations for stream +I/O modules. +They apply to the file descriptor of any open stream object: +terminal, network connection, pipe. +The +.I param +argument is a general pointer which, for these calls, is often +null, a pointer to +.BR int . +The codes are +.TF FIOPUSHLD +.TP +.B FIOPUSHLD +Insert, at the near end of the stream, the line discipline named by +the integer to which +.I param +points. +A census of line discipline modules is given below. +.PD +.TP +.B FIOINSLD +Insert a named line discipline at a given level in a stack +of such modules on the stream. +.I Param +points to a structure containing two short integers +respectively naming the line discipline and the level. +A level of 0 could be accomplished by +.BR FIOPUSHLD . +.TP +.B FIOPOPLD +Pop (removes) the nearest line discipline module, if +.I param +is 0 (null). +If +.I param +points to an integer, the line discipline at that level is removed. +The integer 0 is the same as a null +.IR param . +.TP +.B FIOLOOKLD +Return the number of the topmost line discipline in the stack. +If +.I param +is not 0 but instead points to an integer, the line discipline at that +level is returned in the same integer. +.TP +.B FIOSNDFD +Send the integer file descriptor pointed to by +.IR param +to the process on the other end of pipe +.IR fd . +The code is transmitted directly to the other end of +the pipe, untransformed by line disciplines. +It cannot be forged by the message line discipline, +.IR mesgld (4). +The call returns immediately; it does not rendezvous with +the matching +.BR FIORCVFD . +.TP +.B FIORCVFD +Deliver a structure pointed to by +.IR param : +.EX +struct passfd { + int fd; + short uid; + short gid; + short nice; + char logname[8]; + char cap; +}; +.EE +.IP +The call blocks until there is something in the stream. +If data is present, it returns +.BR EIO . +If a file descriptor has been sent from the other +end of the pipe by +.BR FIOSNDFD , +.B FIORCVFD +fills in the user and group ID of the sending process, +its niceness (see +.IR nice (2)), +its login name, its capabilities in the form of the field +.B lb_t +(see +.IR getflab (2)), +and a file descriptor for the file +being sent; the file is now open in the receiving process. +Another use of +.B FIORCVFD +is described in +.IR connld (4). +.TP +.B FIONREAD +Store, in the integer pointed to by +.IR param , +the number of characters that may be read from this stream +without possible blocking. +.TP +.B FIOGSRC +Copy the stream identifier to the +.BR SSRCSIZ -byte +string pointed to by +.IR param. +.TP +.B FIOSSRC +Copy the +.BR SSRCSIZ -byte +string pointed to by +.I param +into the stream identifier. +Capability +.B T_EXTERN +is required; see +.IR getplab (2). +Empty by default, the stream identifier is customarily +set on network connections to identify the source. +Successful password demands may also be recorded +in the stream identifier for the benefit of +.IR pwserv (8); +see +.IR session (1). +.TP +.B TIOCSPGRP +Make this process the head of a process group and makes this stream +its control stream. +When signals, such as hangup, interrupt, and quit, arrive at +a control stream, they are sent to its process group. +Child processes inherit the process group of their parent. +Process groups are created only by explicit use of this call, +and not implicitly by opening certain devices. +.I Param +must be 0. +.TP +.B TIOCGPGRP +Store through +.I param +a +.B short +naming the process group associated with the stream. +.TP +.B TIOCEXCL +Mark this stream as inaccessible except by the super-user +or by processes in the group associated with this stream. +.TP +.B TIOCNXCL +Remove the inaccessibility of the stream. +.TP +.B TIOCSBRK +Generate a message requesting +a line break. +The message is understood by devices capable of generating it +(such as asynchronous character devices) and ignored otherwise. +.TP +.B TIOCFLUSH +Generate a message causing downstream modules to throw away any +queued characters, if possible. +It applies to both input and output queues. +If the stream serves a device, the flush message may +cause further action in the device driver. +.TP +.B TIOCXFLUSH +Delete all data and messages from input and output queues. +No flush message is passed down the stream or to a +device driver. +.LP +Here is a list of available line discipline modules. +Each is an external integer, defined in +.IR libc ; +see +.IR intro (3). +.TF rmesg_ld +.TP +.B tty_ld +Regular terminal processing; see +.IR ttyld (4). +.TP +.B ntty_ld +Terminal processing according to (modified) Berkeley `new tty' rules; +see Berkeley Users Manual. +.TP +.B cdkp_ld +Character-mode Datakit universal receiver protocol. +.TP +.B dkp_ld +Block-mode Datakit universal receiver protocol. +.TP +.B rdk_ld +.TP +.B uxp_ld +Special Datakit protocols used in connection setup. +.TP +.B buf_ld +Buffering mechanism; +see +.IR bufld (4). +.TP +.B mesg_ld +turns stream control blocks arriving in the read direction into +data messages, and written messages into controls. +See +.IR mesgld (4). +.TP +.B rmesg_ld +inverse of +.BR mesg_ld . +.TP +.B conn_ld +For making unique connections to servers. +See +.IR connld (4). +.TP +.B ip_ld +.TP +.B tcp_ld +.TP +.B udp_ld +.TP +.B arp_ld +Internet protocols; +see +.IR internet (3). +.SH SEE ALSO +.IR ioctl (2), +.IR getstsrc (3) +.br +D. M. Ritchie, +`A Stream I/O System' +.I BLTJ, +October, 1984 +.br +.I +UNIX Programmer's Manual, Seventh Edition, Virtual VAX-11 Version, +1980 (Berkeley) diff --git a/static/unix-v10/man4/tbl.4 b/static/unix-v10/man4/tbl.4 new file mode 100644 index 00000000..bd69ef31 --- /dev/null +++ b/static/unix-v10/man4/tbl.4 @@ -0,0 +1,90 @@ +.TH TBL 4 +.CT 2 tbl_man +.SH NAME +tbl \- kernel table file system +.SH DESCRIPTION +.I Tbl +is a file-system mount point that provides access to kernel data tables. +The name of each entry in the +.F /tbl +directory is the name of a directory +containing files that describe a kernel data table. +These files have the following names and contents: +.PP +.RS +.TF count +.TP +.B base +system base address of the table +.TP +.B count +number of elements in the table +.TP +.B data +table contents +.TP +.B size +size of a table element +.RE +.PD +.PP +The standard system-call interface is used to access +.IR tbl . +.IR Open (2) +and +.IR close (2) +behave as usual. +Data may be transferred +from or to any locations in the ``data'' file through +.I lseek, +.I read, +and +.IR write (2). +.PP +The following header files are useful in analyzing +.I tbl +``data'' files: +.PP +.RS +.TF <sys/param.h> +.TP +.B <sys/file.h> +``file'' structure +.TP +.B <sys/inode.h> +``inode'' structure +.TP +.B <sys/lnode.h> +``lnode'' structure +.TP +.B <sys/param.h> +size parameters +.TP +.B <sys/proc.h> +``proc'' structure +.TP +.B <sys/stream.h> +``stream'', ``block'', and ``queue'' structures +.TP +.B <sys/text.h> +``text'' structure +.TP +.B <sys/types.h> +special system types +.PD +.RE +.SH FILES +.F /tbl/*/base +.br +.F /tbl/*/count +.br +.F /tbl/*/data +.br +.F /tbl/*/size +.SH SEE ALSO +.IR fmount (2), +.IR tblmount (8), +.SH BUGS +The +.I super-user +may write on any file, despite the permissions. diff --git a/static/unix-v10/man4/tc.4 b/static/unix-v10/man4/tc.4 new file mode 100644 index 00000000..6576c60e --- /dev/null +++ b/static/unix-v10/man4/tc.4 @@ -0,0 +1,31 @@ +.pa 1 +.he 'TC (IV)'3/15/72'TC (IV)' +.ti 0 +NAME tc -- TC-11/TU56 DECtape +.sp +.ti 0 +DESCRIPTION The +files tap0 ... tap7 refer to the +TC-11/TU56 DECtape drives 0 to 7. +Since the logical drive number can be manually set, +all eight files exist even though at present there are fewer +physical drives. + +The 256-word blocks on a standard DECtape are numbered 0 to 577. +However, the system makes no assumption about this number; +a block can be read or written if it exists on the +tape and not otherwise. +An error is returned if a transaction +is attempted for a block which does not exist. + +Addressing on the tape files, like that on the +RK and RF disks, is block-oriented. +.sp +.ti 0 +FILES /dev/tap? +.sp +.ti 0 +SEE ALSO rf(IV), tap(I) +.sp +.ti 0 +BUGS see rf(IV) diff --git a/static/unix-v10/man4/tcp.4 b/static/unix-v10/man4/tcp.4 new file mode 100644 index 00000000..8831e5cd --- /dev/null +++ b/static/unix-v10/man4/tcp.4 @@ -0,0 +1,193 @@ +.TH TCP 4 +.CT comm_mach +.SH NAME +tcp, tcp_ld \- DARPA transmission control protocol +.SH SYNOPSIS +.B #include <sys/inio.h> +.br +.B #include <sys/inet/tcp_user.h> +.SH DESCRIPTION +The +.I tcp_ld +line discipline +and the +.F /dev/tcp* +devices together implement the DARPA TCP circuit protocol. +They are normally used through +.IR tcpmgr (8) +and the routines in +.IR ipc (3). +.PP +One instance of +.I tcp_ld +should be pushed on an IP device stream, +usually +.FR /dev/ip6 ; +see +.IR ip (4). +Thereafter, +data written on the +.I tcp +devices is turned into IP packets +written to the IP device, +and vice versa. +.PP +Different +.I tcp +devices represent different software channels. +Files with odd minor device numbers +are for placing calls; +while such a file is open, +it may not be opened again. +Files with even device numbers +receive calls. +.PP +To place a call, +open an unused odd-numbered +.I tcp +file; +write a +.B struct tcpuser +describing the address to be called; +and read a +.B struct tcpuser +for status. +The structure is defined in +.BR <sys/inet/tcp_user.h> : +.PP +.EX +struct tcpuser { + int code; + tcp_port lport, fport; + in_addr laddr, faddr; + int param; +}; + +#define TCPC_LISTEN 1 +#define TCPC_CONNECT 2 + +#define TCPC_OK 3 +#define TCPC_SORRY 4 /* unknown error */ +#define TCPC_BADDEV 5 /* tcp device is bad */ +#define TCPC_NOROUTE 6 /* no routing to dest */ +#define TCPC_BADLOCAL 7 /* bad local address */ +#define TCPC_BOUND 8 /* address already bound */ + +#define SO_KEEPALIVE 0x2 /* generate keepalives */ +.EE +.PP +In the structure describing the call, +.B code +should be +.BR TCPC_CONNECT ; +.B faddr +and +.B fport +are the destination IP address and TCP port number; +.B laddr +is the IP address associated with a local IP interface, +or +.B INADDR_ANY +to let the system pick; +.B lport +is the local TCP port number, +or +0 +to let the system pick; +.B param +is 0 or +.BR SO_KEEPALIVE . +.PP +In the structure returned for status, +.B code +is +.B TCPC_OK +if the call completed correctly; +henceforth data written to and read from the file +is transported on the circuit. +Other codes mean the circuit was not set up. +.PP +To listen for incoming calls, +open an odd-numbered device +and write a +.B struct tcpuser +with +.B code +set to +.BR TCPC_LISTEN ; +.B laddr +set to the local IP address for which calls should be taken, +or +.B INADDR_ANY +to catch any calls not explicitly taken by another listener; +.B lport +set to the port on which to listen, +or 0 for any port; +and +.B param +set to 0. +Thereafter, +reads return successive +.B tcpuser +structures, +each describing a new call; +.B faddr +and +.B fport +identify the caller, +.B laddr +and +.B lport +the assigned local address. +The local +.I tcp +device number, +.I n, +assigned to the call +is returned in +.BR param . +The corresponding device, +.BI /dev/tcp n, +should be opened; +data read and written there is transported by the circuit. +.PP +Several +.IR ioctl (2) +calls, defined in +.BR <sys/inio.h> , +apply to +.I tcp +devices: +.nr Pw \w'\f5TCPIOMAXSEG 'u +.TP \n(Pwu +.B TCPIOHUP +When the remote end of the circuit is disconnected, +send signal +.B SIGHUP +to the local process group associated with the stream. +.TP +.B TCPMAXSEG +The third argument points to an integer +giving the maximum segment size for this connection: +the greatest number of bytes to be packed into one IP packet. +.TP +.B TCPGETADDR +The third argument points to a +.BR "struct tcpuser" ; +fill in +.BR laddr , +.BR lport , +.BR faddr , +and +.BR fport +with the local and foreign addresses associated with the circuit. +.SH FILES +.F /dev/tcp?? +.br +.F /dev/ip6 +.SH SEE ALSO +.IR ip (4), +.IR internet (3), +.IR tcpmgr (8) +.br +DARPA standards RFC 793, 1122 diff --git a/static/unix-v10/man4/tiu.4 b/static/unix-v10/man4/tiu.4 new file mode 100644 index 00000000..219db7e4 --- /dev/null +++ b/static/unix-v10/man4/tiu.4 @@ -0,0 +1,18 @@ +.th TIU IV 10/28/73 +.sh NAME +tiu \*- Spider interface +.sh DESCRIPTION +Spider +is a fast digital switching network. +.it Tiu +is a directory which contains +files each referring to a Spider control +or data channel. +The file /dev/tiu/d\fIn\fR refers to data channel \fIn\fR, +likewise /dev/tiu/c\fIn\fR refers to control channel \fIn\fR. +.s3 +The precise nature of the UNIX interface +has not been defined yet. +.sh FILES +/dev/tiu/d?, /dev/tiu/c? +.sh BUGS diff --git a/static/unix-v10/man4/tm.4 b/static/unix-v10/man4/tm.4 new file mode 100644 index 00000000..470af7b9 --- /dev/null +++ b/static/unix-v10/man4/tm.4 @@ -0,0 +1,38 @@ +.pa 1 +.he 'TM (IV)'6/12/72'TM (IV)' +.ti 0 +NAME tm -- TM-11/TU-10 magtape interface +.sp +.ti 0 +DESCRIPTION mt?___ +is the DEC TU10/TM11 magtape. +When opened for reading or writing, +the magtape is rewound. +A tape consists of a +series of 512 byte records terminated by an +end-of-file. +Reading less than 512 bytes +causes the rest of a record to be ignored. +Writing less than a record causes +null padding to 512 bytes. +When the magtape is closed +after writing, +an end-of-file is written. +.sp +Seek has no effect on the magtape. +The magtape can only be opened once at +any instant. +.sp +.ti 0 +FILES /dev/mt0 selected drive 0 +.sp +.ti 0 +SEE ALSO mt(I) +.sp +.ti 0 +BUGS Seek +should work on the magtape. +Also, a provision of having the tape open for +reading and writing should exist. +A multi-file and multi-reel facility should +be incorporated. diff --git a/static/unix-v10/man4/tty.4 b/static/unix-v10/man4/tty.4 new file mode 100644 index 00000000..7d7a052a --- /dev/null +++ b/static/unix-v10/man4/tty.4 @@ -0,0 +1,114 @@ +.TH TTY 4 +.CT 2 comm_term +.SH NAME +tty \- serial line interface drivers +.SH SYNOPSIS +.B #include <sys/ttyio.h> +.SH DESCRIPTION +The files +.L /dev/tty* +refer to serial line devices +such as the DZ11. +They are normally used in conjunction +with the terminal line discipline, +.IR ttyld (4). +.PP +Certain device-related parameters, +such as parity and line speed, +may be set by +.IR ioctl (2) +calls: +.TF TIOCGDEV +.TP +.B TIOCGDEV +The argument points to a +.B ttydevb +structure to be filled in with current settings. +.TP +.B TIOCSDEV +The argument points to a +.B ttydevb +structure from which the parameters are set. +.PD +.PP +The +.B ttydevb +structure, as defined in +.BR <sys/ttyio.h> , +is +.PP +.EX +.ta \w'struct 'u +\w'ttydevb 'u +\w'ispeed; 'u +struct ttydevb { + char ispeed; /* input speed */ + char ospeed; /* output speed */ + short flags; /* mode flags */ +}; +.EE +.PP +The speeds are encoded as follows. +Impossible speeds are ignored. +.PP +.nf +.ta \w'B9600 'u +5n +\f5B0 0\fP (hang up device) +\f5B50 1\fP 50 baud +\f5B75 2\fP 75 baud +\f5B110 3\fP 110 baud +\f5B134 4\fP 134.5 baud +\f5B150 5\fP 150 baud +\f5B200 6\fP 200 baud +\f5B300 7\fP 300 baud +\f5B600 8\fP 600 baud +\f5B1200 9\fP 1200 baud +\f5B1800 10\fP 1800 baud +\f5B2400 11\fP 2400 baud +\f5B4800 12\fP 4800 baud +\f5B9600 13\fP 9600 baud +\f5EXTA 14\fP External A +\f5EXTB 15\fP External B +.fi +.DT +.PP +The flags are: +.PP +.nf +\f5F8BIT 040\fP eight-bit input and output +\f5ODDP 0100\fP odd parity +\f5EVENP 0200\fP even parity +.fi +.PP +If +.L F8BIT +is set, +all eight bits of each output character +are transmitted +without imposing parity, +and all eight bits of each input character +are passed back without +parity checking or stripping. +Otherwise, +.L EVENP +requests that even parity be accepted and generated, +.L ODDP +odd parity. +If both +.L EVENP +and +.L ODDP +are set, +or if both are clear, +even parity is generated +and any parity is accepted. +.PP +For DZ11 lines, +1200 baud +and 8-bit mode are the defaults. +The transmit and receive speeds are the same; +.B ospeed +is ignored. +.SH SEE ALSO +.IR ioctl (2), +.IR ttyld (4) +.SH BUGS +Every hardware interface doesn't support every operation. diff --git a/static/unix-v10/man4/ttyld.4 b/static/unix-v10/man4/ttyld.4 new file mode 100644 index 00000000..b945a782 --- /dev/null +++ b/static/unix-v10/man4/ttyld.4 @@ -0,0 +1,294 @@ +.TH TTYLD 4 +.CT 2 comm_term +.SH NAME +tty_ld \- terminal processing line discipline +.SH SYNOPSIS +.B #include <sys/ttyio.h> +.SH DESCRIPTION +.I Tty_ld +is usually inserted +into a stream +connected to a terminal device. +It gathers input into lines, +handles special characters like erase, kill, and interrupt, +inserts output delays, +and the like. +It does not deal with hardware parameters +such as speed and parity; +see +.IR tty (4) +for such matters. +.PP +Certain special characters have particular meaning on input. +These characters are not passed to a program +except in raw mode, where they lose their special character. +It is possible to change these characters from the default. +.PP +The +.I erase +character +(default +.BR # ) +erases the last-typed character. +It will not erase beyond the beginning of a line or +an end-of-file character. +.PP +The +.I kill +character +(default +.BR @ ) +erases the entire preceding part of the line, but not beyond +an end-of-file character. +.PP +The +.I end-of-file +character +(default +.RB control- d ) +causes any characters +waiting to be read +to be passed immediately +to the program, +without waiting for newline. +The +end-of-file character itself is discarded. +Thus if the end-of-file character +occurs at the beginning of a line, +there are no characters waiting, +and zero characters will be passed back; +this is +the standard end-of-file indication. +.PP +The +.I escape +character +.RB ( \e ) +escapes a following erase, kill, or end-of-file character +and allows it to be treated as ordinary data. +.PP +The +.I interrupt +character +(default +DEL) +is not passed to a program but sends +signal +.L SIGINT +to any processes in the process group of the stream; +see +.IR signal (2) +and +.IR stream (4). +.PP +The +.I quit +character +(default +FS, +.RB control- \e ) +sends signal +.BR SIGQUIT . +.PP +The +.I stop +character +(default DC3, +.RB control- s ) +delays printing on the terminal +until something is typed in. +.PP +The +.I start +character +(default DC1, +.RB control- q ) +restarts printing after +a stop character without generating +any input to a program. +.PP +Two +.IR ioctl (2) +calls affect these characters: +.TF TIOCGETC +.TP +.B TIOCGETC +The argument points to a +.B tchars +structure to be filled in with current settings. +.TP +.B TIOCSETC +The argument points to a +.B tchars +structure from which the characters are set. +.PD +.PP +The +.B tchars +structure, as defined in +.LR <sys/ttyio.h> , +is +.PP +.EX +.ta \w'struct 'u +\w'tchars 'u +\w't_startc; 'u +struct tchars { + char t_intrc; /* interrupt */ + char t_quitc; /* quit */ + char t_startc; /* start output */ + char t_stopc; /* stop output */ + char t_eofc; /* end-of-file */ + char t_brkc; /* input delimiter (like nl) */ +}; +.EE +.PP +A character value of 0377 +eliminates the effect of that character. +The +.L t_brkc +character, by default 0377, +acts like a new-line in that it terminates a line, +is echoed, and is passed to the program. +The stop and start characters may be the same, +to produce a toggle effect. +It is counterproductive to make +other special characters (including erase and kill) +identical. +.PP +Two +.I ioctl +calls affect other terminal processing parameters: +.TF TIOCGETP +.TP +.B TIOCGETP +The argument points to a +.B sgttyb +structure to be filled in with the current settings. +.TP +.B TIOCSETP +The argument points to a +.B sgttyb +structure from which the parameters are set. +.PD +.PP +The +.B sgttyb +structure, as +defined in +.LR <sys/ttyio.h> , +is +.EX +.ta \w'struct 'u +\w'sgttyb 'u +\w'sg_ispeed 'u +struct sgttyb { + char sg_ispeed; /* unused */ + char sg_ospeed; /* unused */ + char sg_erase; /* erase character */ + char sg_kill; /* kill character */ + short sg_flags; /* mode flags */ +}; +.EE +.PP +The flag bits are +.PP +.ta \w'\f5ALLDELAY\fP 'u +\w'\f50100000\fP 'u +.nf +\f5ALLDELAY 0177400\fP Delay algorithm selection +\f5VTDELAY 0040000\fP Form-feed and vertical-tab delays: +\f5FF0 0\fP +\f5FF1 0040000\fP +\f5CRDELAY 0030000\fP Carriage-return delays: +\f5CR0 0\fP +\f5CR1 0010000\fP +\f5CR2 0020000\fP +\f5CR3 0030000\fP +\f5TBDELAY 0006000\fP Tab delays: +\f5TAB0 0\fP +\f5TAB1 0002000\fP +\f5TAB2 0004000\fP +\f5XTABS 0006000\fP +\f5NLDELAY 0001400\fP New-line delays: +\f5NL0 0\fP +\f5NL1 0000400\fP +\f5NL2 0001000\fP +\f5NL3 0001400\fP +\f5RAW 0000040\fP Raw mode: wake up on all characters +\f5CRMOD 0000020\fP Map CR into LF; echo LF or CR as CR-LF +\f5ECHO 0000010\fP Echo (full duplex) +\f5LCASE 0000004\fP Map upper case to lower on input +\f5CBREAK 0000002\fP Return each character as soon as typed +\f5TANDEM 0000001\fP Automatic flow control +.DT +.fi +.PP +The delay bits specify how long +transmission stops to allow for mechanical or other movement +when certain characters are sent to the terminal. +In all cases a value of 0 indicates no delay. +.PP +If a form-feed/vertical tab delay is specified, +it lasts for about 2 seconds. +.PP +Carriage-return delay type 1 lasts about .08 seconds; +type 2 about .16 seconds; +type 3 about .32 seconds. +.PP +New-line delay type 1 is supposed to be for the Teletype model 37; +type 2 is about .10 seconds. +.PP +Tab delay type 1 is supposed to be for the Teletype model 37. +Type 3, called +.LR XTABS , +is not a delay at all but causes tabs to be replaced +by the appropriate number of spaces on output. +.PP +In +.B RAW +mode, +every character is passed immediately +to the program without waiting until a full line has been typed. +No erase or kill processing is done; +the end-of-file, interrupt, and quit characters +are not treated specially. +There are no delays and no echoing, and no replacement of +one character for another. +.PP +.L CRMOD +causes input carriage returns to be turned into +new-lines; +input of either CR or LF causes CR-LF both to +be echoed +(for terminals without a new-line function). +.PP +.L CBREAK +is a sort of half-cooked mode. +Programs read each character as soon as typed, instead +of waiting for a full line, +but quit and interrupt work, and output delays +.LR CRMOD , +.LR XTABS , +and +.LR ECHO +work normally. +On the other hand there is no erase or kill, +and no special treatment of +.L \e +or end-of-file. +.PP +.L TANDEM +mode causes the system to transmit +the stop character whenever the input +queue is in danger of overflowing, +and the start character +when the input queue has drained sufficiently. +It is useful for flow control when the `terminal' +is actually another machine that obeys the conventions. +.SH SEE ALSO +.IR getty (8), +.IR stty (1), +.IR signal (2), +.IR ioctl (2), +.IR stream (4), +.IR tty (4) +.SH BUGS +The +escape character +cannot be changed. diff --git a/static/unix-v10/man4/up.4 b/static/unix-v10/man4/up.4 new file mode 100644 index 00000000..3198f630 --- /dev/null +++ b/static/unix-v10/man4/up.4 @@ -0,0 +1,65 @@ +.TH UP 4 +.SH NAME +up \- emulex sc21/ampex 9300 UNIBUS moving head disk +.SH DESCRIPTION +Files with minor device numbers 0 through 7 refer to various portions +of drive 0; +minor devices 8 through 15 refer to drive 1, etc. +.PP +The origin and size of the pseudo-disks on each drive are +as follows: +.PP +.ta .5i +\w'000000 'u +\w'000000 'u +.nf +9300 partitions + disk start byte + 0 0 15884 + 1 16416 33440 + 2 0 500992 + 3 341696 15884 + 4 358112 55936 + 5 414048 36944 + 6 341696 159296 + 7 49856 291346 +.DT +.fi +.PP +The +block +files +access the disk via the system's normal +buffering mechanism +and may be read and written without regard to +physical disk records. +There is also a `raw' interface +which provides for direct transmission between the disk +and the user's read or write buffer. +A single read or write call results in exactly one I/O operation +and therefore raw I/O is considerably more efficient when +many words are transmitted. +The names of the raw files +conventionally +begin with +an extra `r.' +.SH FILES +.ta 2i +/dev/up[0-3][a-h] block files +.br +/dev/rup[0-3][a-h] raw files +.SH SEE ALSO +rp(4) +.SH BUGS +In raw I/O +.I read +and +.IR write (2) +truncate file offsets to 512-byte block boundaries, +and +.I write +scribbles on the tail of incomplete blocks. +Thus, +in programs that are likely to access raw devices, +.I read, write +and +.IR lseek (2) +should always deal in 512-byte multiples. diff --git a/static/unix-v10/man4/va.4 b/static/unix-v10/man4/va.4 new file mode 100644 index 00000000..943fb2ba --- /dev/null +++ b/static/unix-v10/man4/va.4 @@ -0,0 +1,121 @@ +.TH VA 4 +.UC 4 +.SH NAME +va \- Benson-Varian interface +.SH SYNOPSIS +.B #include <sys/vcmd.h> +.SH DESCRIPTION +The Benson-Varian printer/plotter in normally used with the programs +.IR vpr (1), +.IR vprint (1) +or +.IR vtroff (1). +This description is designed for those who wish to drive the Benson-Varian +directly. +.PP +The Benson-Varian at Berkeley uses 11\*(rq by 8\*(rq fan-fold paper. +It will print 132 characters per line in print mode +and 2112 dots per line in plot mode. +.PP +In print mode, the Benson-Varian uses a modified ASCII character set. +Most control characters print various non-ASCII graphics such as daggers, +sigmas, copyright symbols, etc. +Only LF and FF are used as format effectors. LF acts as a newline, +advancing to the beginning of the next line, and FF advances to the top of +the next page. +.PP +In plot mode, the Benson-Varian prints one raster line at a time. +An entire raster line of bits (2112 bits = 264 bytes) is sent, and +then the Benson-Varian advances to the next raster line. +.PP +.B Note: +The Benson-Varian must be sent an even number of bytes. +If an odd number is sent, the last byte will be lost. +Nulls can be used in print mode to pad to an even number of bytes. +.PP +To use the Benson-Varian yourself, you must realize that you cannot open the +device, +.I /dev/va0 +if there is a daemon active. +You can see if there is a daemon active by doing a +.IR ps (1), +or by looking in the directory +.I /usr/spool/vad. +If there is a file +.I lock +there, then there is probably a daemon +.IR /usr/lib/vad +running. +If not, you should remove the +.I lock. +.PP +In any case, when your program tries to open the device +.I /dev/va0 +you may get one of two errors. +The first of these +ENXIO +indicates that the Benson-Varian is already in use. +Your program can then +.IR sleep (2) +and try again in a while, or give up. +The second is +EIO +and indicates that the Benson-Varian is offline. +.PP +To set the Benson-Varian into plot mode you can use the following +.IR ioctl (2) +call +.IP +ioctl(fileno(va), VSETSTATE, plotmd); +.PP +where +.B plotmd +is defined to be +.IP +\fBint\fR plotmd[] = { VPLOT, 0, 0 }; +.PP +and +.I va +is the result of a call to +.I fopen +on stdio. +When you finish using the Benson-Varian in plot mode you should advance to +a new page +by sending it a FF after putting it back into print mode, i.e. by +.sp .1i +'nf +\fBint\fR prtmd[] = { VPRINT, 0, 0 }; +\&... +fflush(va); +ioctl(fileno(va), VSETSTATE, prtmd); +write(fileno(va), "\ef\e0", 2); +.fi +.PP +.IR N.B. : +If you use the standard I/O library with the Benson-Varian you +.B must +do +.IP +setbuf(vp, vpbuf); +.PP +where +.I vpbuf +is declared +.IP +\fBchar\fR vpbuf[BUFSIZ]; +.PP +otherwise the standard I/O library, thinking that the Benson-Varian +is a terminal (since it is a character special file) will not adequately buffer +the data you are sending to the Benson-Varian. +This will cause it to run +.B extremely +slowly and tends to grind the system to a halt. +.SH FILES +/dev/va0 +.br +/usr/include/sys/vcmd.h +.SH SEE ALSO +vfont(5), vpr(1), vtroff(1), vp(4) +.SH BUGS +The 1's (one's) and l's (lower-case el's) in the Benson-Varian's +standard character set look very similar; caution is advised. diff --git a/static/unix-v10/man4/vc.4 b/static/unix-v10/man4/vc.4 new file mode 100644 index 00000000..6f0ddb8f --- /dev/null +++ b/static/unix-v10/man4/vc.4 @@ -0,0 +1,64 @@ +.TH VC 4 +.CT 2 graphics +.SH NAME +vc \- versatec model 122 interface +.SH SYNOPSIS +.B #include <sys/vcio.h> +.SH DESCRIPTION +The files +.I vc[0-9] refer to the Versatec model 122 interface. Any plotter obeying +the Versatec "green sheet" interface standard can be used with this interface. +.PP +Upon opening the device, a RESET_ALL command is executed by the driver. +The driver will only accept a +.I write +or an +.IR ioctl (2) +; reads will fail and seeks are ignored. +.PP +.IR ioctl (2) +calls perform special operations. There are two basic calls: VGETSTATE +and VSETSTATE. VSETSTATE can be used to send special commands to the plotter +by setting bits in the control status register (CSR). +VGETSTATE returns the CSR of the interface. The functions are specified in +vcio.h. The bits are as follows: +.TP +.B VC_SPP +is "Simultaneous Print/Plot" +.TP +.B VC_PP +is print/plot mode. Data bytes sent in print mode are printed using the ROM +in the plotter. Bytes written in plot mode are plotted. It is possible to +use print mode to send commands to the plotter. See the manual for details. +.TP +.B VC_SWPBT +swaps the bytes in the interface. Useful for the VAX. +.PP +The remote operations are sent one at a time. +.TF VC_RLTER +is short for +.I "Remote Line Terminate". +It sends a line terminator to the Versatec. +.TP +.B VC_CLEAR +clears the buffer. +.TP +.B VC_RESET +will reset the controller and the plotter. +.TP +.B VC_RFFED +is short for +.I "Remote Form Feed" +and will advance the paper. +.TP +.B VC_REOTR +is short for +.I "Remote End of Transmission" +which is equivalent to sending an EOF. +.TP +.B VC_RESET_ALL +is the ultimate reset. +.PD +.SH FILES +.F /dev/vc? +.SH BUGS diff --git a/static/unix-v10/man4/vp.4 b/static/unix-v10/man4/vp.4 new file mode 100644 index 00000000..f99cd393 --- /dev/null +++ b/static/unix-v10/man4/vp.4 @@ -0,0 +1,100 @@ +.TH VP 4 2/21/80 4 +.UC 4 +.SH NAME +vp \- Versatec interface +.SH SYNOPSIS +.B #include <sys/vcmd.h> +.SH DESCRIPTION +The Versatec printer/plotter in normally used with the programs +.IR vpr (1), +.IR vprint (1) +or +.IR vtroff (1). +This description is designed for those who wish to drive the Versatec directly. +.PP +The Versatec at Berkeley is 36\*(rq wide, and has 440 characters per line +and 7040 dots per line in plot mode (this is actually slightly less than +36\*(rq of dots.) +The paper used is continuous roll paper, and comes in 500' rolls. +.PP +To use the Versatec yourself, you must realize that you cannot open the +device, +.I /dev/vp0 +if there is a daemon active. +You can see if there is a daemon active by doing a +.IR ps (1), +or by looking in the directory +.I /usr/spool/vpd. +If there is a file +.I lock +there, then there is probably a daemon +.IR /usr/lib/vpd +running. +If not, you should remove the +.I lock. +.PP +In any case, when your program tries to open the device +.I /dev/vp0 +you may get one of two errors. +The first of these +ENXIO +indicates that the Versatec is already in use. +Your program can then +.IR sleep (2) +and try again in a while, or give up. +The second is +EIO +and indicates that the Versatec is offline. +.PP +To set the Versatec into plot mode you can use the following +.IR ioctl (2) +call +.IP +ioctl(fileno(vp), VSETSTATE, plotmd); +.PP +where +.B plotmd +is defined to be +.IP +\fBint\fR plotmd[] = { VPLOT, 0, 0 }; +.PP +and +.I vp +is the result of a call to +.I fopen +on stdio. +When you finish using the Versatec in plot mode you should eject paper +by sending it a EOT after putting it back into print mode, i.e. by +.sp .1i +'nf +\fBint\fR prtmd[] = { VPRINT, 0, 0 }; +\&... +fflush(vp); +ioctl(fileno(vp), VSETSTATE, prtmd); +write(fileno(vp), "\e04", 1); +.fi +.PP +.IR N.B. : +If you use the standard I/O library with the Versatec you +.B must +do +.IP +setbuf(vp, vpbuf); +.PP +where +.I vpbuf +is declared +.IP +\fBchar\fR vpbuf[BUFSIZ]; +.PP +otherwise the standard I/O library, thinking that the Versatec +is a terminal (since it is a character special file) will not adequately buffer +the data you are sending to the Versatec. +This will cause it to run +.B extremely +slowly and tends to grind the system to a halt. +.SH FILES +/dev/vp0 +.SH SEE ALSO +vfont(5), vpr(1), vtroff(1), va(4) +.SH BUGS diff --git a/static/unix-v10/man4/vs.4 b/static/unix-v10/man4/vs.4 new file mode 100644 index 00000000..688c4fc7 --- /dev/null +++ b/static/unix-v10/man4/vs.4 @@ -0,0 +1,20 @@ +.th VS IV 10/28/73 +.sh NAME +vs \*- voice synthesizer interface +.sh DESCRIPTION +Bytes written on +.it vs +drive a Federal Screw Works Votrax\(rg +voice synthesizer. +The upper two bits encode an inflection, the other 6 specify a phoneme. +The code is given in section vs (VII). +.s3 +Touch-Tone\(rg signals sent by a caller will be +picked up during a +.it read +as the ASCII characters {0123456789#*}. +.sh FILES +/dev/vs +.sh "SEE ALSO" +speak (I), vs (VII) +.sh BUGS diff --git a/static/unix-v10/man4/vt.4 b/static/unix-v10/man4/vt.4 new file mode 100644 index 00000000..a74d00c2 --- /dev/null +++ b/static/unix-v10/man4/vt.4 @@ -0,0 +1,230 @@ +.pa 1 +.he 'VT (IV)'2/11/73'VT (IV)' +.ti 0 +NAME vt -- 11/20 (vt01) interface +.sp +.ti 0 +DESCRIPTION +.br +.in 8 +The file vt0___ provides +the interface to a PDP 11/20 which +runs both a VT01A-controlled Tektronix 611 +storage display, +and a Federal Screw Works (Vocal Interface Division) +voice synthesizer. +The inter-computer interface is +a pair of DR-11C word interfaces. + +Although the display has essentially only two commands, +namely "erase screen" and "display point", the 11/20 program +will draw points, lines, and arcs, and print +text on the screen. +The 11/20 can also type information +on the attached 33 TTY and generate utterances via the +voice synthesizer. + +This special file operates in two basic modes, selected +by bit 2 (octal 04) on the 11/20's console switches. +If this bit is on at the opening of the file, +all bytes written on the file are interpreted as ASCII characters +and written on the screen. +The screen has 33 lines (1/2 a standard page). +The file simulates a 37 TTY: the control characters +NL, CR, BS, and TAB are interpreted correctly. +It also interprets the usual escape sequences +for forward and reverse half-line motion and for +full-line reverse. +Greek is not available yet. +Normally, when the screen is full (i.e. the 34th line is started) +the screen is erased before starting a new page. +To allow perusal of the displayed text, it is usual to +assert bit 0 of the console switches (octal 01). +As explained below, this causes the program to +pause before erasing until one of the attached pushbuttons +is depressed. + +If bit 2 of the switches is down, the display is in graphic +mode. +In this case bytes written on the file +are interpreted as display and vocal +commands. +Each command consists of a single byte usually followed +by parameter bytes. +Often the parameter bytes represent +points in the plotting area. +Each point coordinate consists of 2 bytes +interpreted as a 2's complement 16-bit number. +The plotting area itself measures (+_03777)X(+_03777) +(numbers in octal); +that is, 12 bits of precision. +Attempts to plot +points outside the screen limits are ignored. + +The graphic and sonic commands are: + +.in +5 +.ti -5 +order (1); 1 parameter byte +.br +The parameter indicates a subcommand, possibly followed +by subparameter bytes, as follows: +.in +5 + +.ti -5 +erase (1) +.br +The screen is erased. +This action may be delayed, as explained below, +until a pushbutton is depressed. + +.ti -5 +label (2); several subparameter bytes +.br +The following bytes up to a null character +are taken as a label and typed on the console TTY. +One of the console switches gives labels +a special interpretation, as explained below. + +.ti -5 +.nf +display label (3); several subparameter bytes +.fi +.br +The following bytes up to a null byte are printed +as ASCII text on the screen. +The origin of the text is the last previous point +plotted; or the upper left hand of the screen if there were none. + +.in -5 +.ti -5 +point (2); 4 parameter bytes +.br +The 4 parameter bytes are taken as a pair of coordinates +representing a point to be plotted. + +.ti -5 +line (3); 8 parameter bytes +.br +The parameter bytes are taken as 2 pairs of coordinates +representing the ends of a line segment which is plotted. +Only the portion lying within the screen is displayed. + +.ti -5 +frame (4); 1 parameter byte +.br +The parameter byte is taken as a number of sixtieths of a second; +an externally-available lead is asserted for that time. +Typically the lead is connected to +an automatic camera +which advances its film and opens the +shutter for the specified time. + +.ti -5 +circle (5); 6 parameter bytes +.br +The parameter bytes are taken as a coordinate pair representing +the origin, and a word representing the radius of a circle. +That portion of the circle which lies within the screen is plotted. + +.ti -5 +arc (6); 12 parameter bytes +.br +The first 4 parameter bytes are taken to be a coordinate-pair +representing the center of a circle. +The next 4 represent a coordinate-pair specifying a point +on this circle. +The last 4 should represent another point on the +circle. +An arc is drawn counter-clockwise from the first circle point +to the second. +If the two points are the same, the whole circle is drawn. +For the second point, only the smaller in magnitude +of its two coordinates is significant; +the other is used only to find the quadrant of the end of the arc. +In any event only points within the screen limits are +plotted. + +.ti -5 +dot-line (7); at least 6 parameter bytes +.br +The first 4 parameter bytes are taken +as a coordinate-pair representing the origin +of a dot-line. +The next byte is taken as a signed +x-increment. +The next byte is an unsigned word-count, +with "0" meaning "256". +The indicated +number of words is picked up. +For each bit in each word a point is plotted +which is visible if the bit is "1", invisible +if not. +High-order bits are plotted first. +Each successive point (or non-point) is offset +rightward by the given x-increment. + +.ti -5 +speak(8); several parameter bytes +.br +The following bytes up to a null byte are taken +to represent phonemes which are fed to +the voice synthesizer. +vsp(VII) gives the encoding. + +.in -5 +The 3 low-order console switches of the 11/20 +modify the operation of the display as follows. + +Bit 2 (octal 04) is examined at the time the display +file is opened (more precisely, when the first byte +is written after an open); as indicated, +when on__ it selects character mode, otherwise graphic +mode. + +Bit 1 (octal 02) +determines whether TTY labels are to be interpreted. +Unless this bit is on__, labels are ignored. +(except to terminate skip mode, see below). + +Bit 0 (octal 01) determines +whether the display will pause before erasing +the screen; +if off___ there will be no pause. +.a +If bit 0 is on__, the erase will occur +and displaying will resume only when one of the +16 pushbuttons is depressed. + +There is a box with 16 pushbuttons connected +to the 11/20. +Their state is at all times available in the 11/45 +by executing the csw___ system call (II). +They are used by the 11/20 when it is pausing +before an erase. +14 of the buttons merely serve to allow the display +to continue. +If, however, button 7 +is pushed, +the display will ignore commands up to the +next erase command, then ring the TTY console's bell, +thereby skipping an entire picture. + +If button 8 is depressed, +the display will ignore commands up to the next TTY label +(whether or not its typing is suppressed) before +resuming the displays. +Thus a sequence of frames may be skipped. +.sp +.in 16 +.ti 0 +FILES /dev/vt0 +.sp +.ti 0 +SEE ALSO csw(II), vsp(VII) +.sp +.ti 0 +BUGS Two +users using vt0 simultaneously +can interfere with each other, +e.g. plot phonemes or speak display coordinates. |