build: Better Build System

author: Jacob McDonnell <jacob@jacobmcdonnell.com> 2026-04-26 16:38:00 -0400
committer: Jacob McDonnell <jacob@jacobmcdonnell.com> 2026-04-26 16:38:00 -0400
commit: 97d5c458cfa039d857301e1ca7d5af3beb37131d (patch)
tree: b460cd850d0537eb71806ba30358840377b27688 /static/plan9-4e/man3
parent: b89dc2331a50c63f8b33272a5c4c61ab98abdaa3 (diff)
35 files changed, 5716 insertions, 0 deletions
diff --git a/static/plan9-4e/man3/0intro.3 b/static/plan9-4e/man3/0intro.3
new file mode 100644
index 00000000..a1b30193
--- /dev/null
+++ b/static/plan9-4e/man3/0intro.3
@@ -0,0 +1,92 @@
+.TH INTRO 3 
+.SH NAME
+intro \- introduction to the Plan 9 devices
+.SH DESCRIPTION
+A Plan 9
+.I device
+implements a file tree for client processes.
+A file name beginning with a pound sign, such as
+.LR #c ,
+names the root of a file tree implemented by
+a particular
+.IR "kernel device driver"
+identified by the character after the pound sign.
+Such names are usually bound to conventional locations
+in the name space.
+For example, after
+.IP
+.EX
+bind("#c", "/dev", MREPL)
+.EE
+.LP
+an
+.IR ls (1)
+of
+.B /dev
+will list the files provided by the
+.I console
+device.
+.PP
+A kernel device driver is a
+.I server
+in the sense of the Plan 9 File Protocol, 9P (see Section 5),
+but with the messages implemented by local
+rather than remote procedure calls.
+Also, several of the messages
+.RI ( Nop ,
+.IR Session ,
+.IR Flush ,
+and
+.IR Error )
+have no subroutine equivalents.
+.PP
+When a system call is passed a file name beginning with
+.L "#"
+it looks at the next character, and if that is a valid
+.I device character
+it performs an
+.IR attach (5)
+on the corresponding device to get a channel representing the
+root of that device's file tree.
+If there are any characters after the device character but
+before the next
+.L "/"
+or end of string, those characters are passed as parameter
+.I aname
+to the attach.  For example,
+.IP
+.EX
+#I2
+.EE
+.PP
+identifies the number 2 IP protocol stack
+(see
+.IR ip (3)).
+.PP
+Each kernel device has a conventional place at which to be bound
+to the name space.
+The
+.I SYNOPSIS
+sections of the following pages includes a
+.I bind
+command to put the device in the conventional place.
+Most of these binds are done automatically by
+.IR init (8)
+using
+.B newns
+(see
+.IR auth (2))
+on the file
+.B /lib/namespace
+(see
+.IR namespace (6)).
+When typed to
+.IR rc (1),
+the
+.I bind
+commands will need quotes to protect the
+.B #
+characters.
+.SH SEE ALSO
+.IR intro (5),
+.IR intro (2)
diff --git a/static/plan9-4e/man3/INDEX.3 b/static/plan9-4e/man3/INDEX.3
new file mode 100644
index 00000000..2cdb56b1
--- /dev/null
+++ b/static/plan9-4e/man3/INDEX.3
@@ -0,0 +1,35 @@
+0intro 0intro
+intro 0intro
+apm apm
+arch arch
+audio audio
+cap cap
+cons cons
+draw draw
+dup dup
+env env
+ether ether
+floppy floppy
+i82365 i82365
+ip ip
+kprof kprof
+loopback loopback
+lpt lpt
+mnt mnt
+cursor mouse
+mouse mouse
+pipe pipe
+pnp pnp
+proc proc
+realtime realtime
+root root
+rtc rtc
+sd sd
+segment segment
+srv srv
+ssl ssl
+tls tls
+eia uart
+uart uart
+usb usb
+vga vga
diff --git a/static/plan9-4e/man3/INDEX.html.3 b/static/plan9-4e/man3/INDEX.html.3
new file mode 100644
index 00000000..8d7d5352
--- /dev/null
+++ b/static/plan9-4e/man3/INDEX.html.3
@@ -0,0 +1,137 @@
+<HEAD>
+<TITLE>plan 9 man section 3</TITLE>
+</HEAD>
+<BODY>
+<B>[<A HREF="/sys/man/index.html">manual index</A>]</B>
+<H2>Plan 9 from Bell Labs - Section 3 - Devices</H2>
+<HR>
+<DL>
+<DT><A HREF="/magic/man2html/3/0intro">0intro</A>
+-  introduction to the Plan 9 devices
+<DD><TT> intro</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/apm">apm</A>
+-  Advanced Power Management 1.2 BIOS interface
+<DD><TT> apm</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/arch">arch</A>
+-  architecture-specific information and control
+<DD><TT> arch</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/audio">audio</A>
+-  SoundBlaster audio controller
+<DD><TT> audio</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/cap">cap</A>
+-  capabilities for setting the user id of processes
+<DD><TT> cap</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/cons">cons</A>
+-  console, clocks, process/process group ids, user, null, reboot, etc.
+<DD><TT> cons</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/draw">draw</A>
+-  screen graphics
+<DD><TT> draw</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/dup">dup</A>
+-  dups of open files
+<DD><TT> dup</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/env">env</A>
+-  environment variables
+<DD><TT> env</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/ether">ether</A>
+-  Ethernet device
+<DD><TT> ether</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/floppy">floppy</A>
+-  floppy disk interface
+<DD><TT> floppy</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/i82365">i82365</A>
+-  Personal Computer Memory Card Interface Association (PCMCIA) device
+<DD><TT> i82365</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/ip">ip</A>
+-  network protocols over IP
+<DD><TT> ip</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/kprof">kprof</A>
+-  kernel profiling
+<DD><TT> kprof</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/loopback">loopback</A>
+-  network link simulation
+<DD><TT> loopback</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/lpt">lpt</A>
+-  parallel port interface for PC's
+<DD><TT> lpt</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/mnt">mnt</A>
+-  attach to 9P servers
+<DD><TT> mnt</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/mouse">mouse</A>
+-  kernel mouse interface
+<DD><TT> mouse, cursor</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/pipe">pipe</A>
+-  two-way interprocess communication
+<DD><TT> pipe</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/pnp">pnp</A>
+-  Plug 'n' Play ISA and PCI Interfaces
+<DD><TT> pnp</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/proc">proc</A>
+-  running processes
+<DD><TT> proc</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/realtime">realtime</A>
+-  real time scheduling
+<DD><TT> realtime</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/root">root</A>
+-  the root file system
+<DD><TT> root</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/rtc">rtc</A>
+-  real-time clock and non-volatile RAM
+<DD><TT> rtc</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/sd">sd</A>
+-  storage device interface
+<DD><TT> sd</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/segment">segment</A>
+-  long lived memory segments
+<DD><TT> segment</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/srv">srv</A>
+-  server registry
+<DD><TT> srv</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/ssl">ssl</A>
+-  SSL record layer
+<DD><TT> ssl</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/tls">tls</A>
+-  TLS1 and SSL3 record layer
+<DD><TT> tls</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/uart">uart</A>
+-  serial communication control
+<DD><TT> uart, eia</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/usb">usb</A>
+-  USB Host Controller Interface
+<DD><TT> usb</TT>
+</DT>
+<DT><A HREF="/magic/man2html/3/vga">vga</A>
+-  VGA controller device
+<DD><TT> vga</TT>
+</DT>
+</DL>
diff --git a/static/plan9-4e/man3/Makefile b/static/plan9-4e/man3/Makefile
new file mode 100644
index 00000000..c070e829
--- /dev/null
+++ b/static/plan9-4e/man3/Makefile
@@ -0,0 +1,3 @@
+MAN = $(wildcard *.3)
+
+include ../../mandoc.mk
diff --git a/static/plan9-4e/man3/apm.3 b/static/plan9-4e/man3/apm.3
new file mode 100644
index 00000000..36809ea5
--- /dev/null
+++ b/static/plan9-4e/man3/apm.3
@@ -0,0 +1,60 @@
+.TH APM 3
+.SH NAME
+apm \- Advanced Power Management 1.2 BIOS interface
+.SH SYNOPSIS
+.nf
+.B bind -a #P /dev
+
+.B /dev/apm
+.SH DESCRIPTION
+.PP
+This device presents a low-level interface to
+the APM 1.2 bios calls.
+It is enabled by adding the line
+.RB `` apm0= ''
+to 
+.IR plan9.ini .
+(The value after the equals sign is ignored; the presence of
+the line at all enables the driver.)
+It is only available on uniprocessor PCs.
+Writing a 386
+.B Ureg
+structure and then reading it back executes an APM call:
+the written registers are passed to the call,
+and the read registers are those returned by the call.
+.\" .PP
+.\" In addition, the following strings may be
+.\" written to
+.\" .B /dev/apm
+.\" to negotiate with other kernel devices about
+.\" suspension of the system.
+.\" .TP
+.\" .B "vote suspend
+.\" Poll kernel devices for objections to suspending the system.
+.\" The write succeeds only when no device objected.
+.\" .TP
+.\" .B "abort suspend
+.\" Notify kernel devices that the vote failed and the
+.\" suspension will not happen.
+.\" .TP
+.\" .B "commit suspend
+.\" Notify kernel devices that the vote succeeded and
+.\" suspension will happen.  The devices
+.\" may take measures such as disabling PCMCIA cards.
+.\" .TP
+.\" .B "resume suspend
+.\" Notify kernel devices that the system has come back
+.\" after a suspension.
+.\" The devices may take measures such as reenabling PCMCIA cards.
+.\" .PD
+.\" A similar set of messages governs entrance into
+.\" .B standby
+.\" mode.
+.PP
+This device is intended to enable more user-friendly
+interfaces such as 
+.IR apm (8).
+.SH SOURCE
+.B /sys/src/9/pc/apm.c
+.br
+.B /sys/src/9/pc/apmjump.s
diff --git a/static/plan9-4e/man3/arch.3 b/static/plan9-4e/man3/arch.3
new file mode 100644
index 00000000..25a5331a
--- /dev/null
+++ b/static/plan9-4e/man3/arch.3
@@ -0,0 +1,65 @@
+.TH ARCH 3
+.SH NAME
+arch \- architecture-specific information and control
+.SH SYNOPSIS
+.nf
+.B bind -a #P /dev
+
+.B /dev/cputype
+.B /dev/ioalloc
+.B /dev/iob
+.B /dev/iol
+.B /dev/iow
+.B /dev/irqalloc
+.SH DESCRIPTION
+.PP
+This device presents textual information about PC hardware and allows
+user-level control of the I/O ports on x86-class and DEC Alpha machines.
+.PP
+Reads from
+.I cputype
+recover the processor type and clock rate.
+.PP
+Reads from
+.I ioalloc
+return I/O ranges used by each device, one line
+per range.  Each line contains three fields separated by white space: first address
+in hexadecimal,
+last address, name of device.
+.PP
+Reads from
+.I irqalloc
+return the enabled interrupts, one line per
+interrupt.  Each line contains three fields separated by white space:
+the trap number, the IRQ it is assigned to, and the name of
+the device using it.
+.PP
+Reads and writes to
+.IR iob ,
+.IR iow ,
+and
+.I iol
+cause 8-bit wide, 16-bit wide, and 32-bit wide requests to
+I/O ports.
+The port accessed is determined by the byte offset of the
+file descriptor.
+.SH EXAMPLE
+The following code reads from an x86 byte I/O port.
+.IP
+.EX
+uchar
+inportb(long port)
+{
+    uchar data;
+
+    if(iobfd == -1)
+        iobfd = open("#P/iob", ORDWR);
+
+    seek(iobfd, port, 0);
+    if(read(iobfd, &data, sizeof(data)) != sizeof(data))
+        sysfatal("inportb(0x%4.4x): %r\en", port);
+    return data;
+}
+.EE
+.SH SOURCE
+.B /sys/src/9/pc/devarch.c
diff --git a/static/plan9-4e/man3/audio.3 b/static/plan9-4e/man3/audio.3
new file mode 100644
index 00000000..caceffdb
--- /dev/null
+++ b/static/plan9-4e/man3/audio.3
@@ -0,0 +1,129 @@
+.TH AUDIO 3 
+.SH NAME
+audio \- SoundBlaster audio controller
+.SH SYNOPSIS
+.nf
+.B bind -a #A /dev
+
+.B /dev/audio
+.B /dev/volume
+.fi
+.SH DESCRIPTION
+.PP
+The audio device serves a one-level directory,
+giving access to the stereo audio ports.
+.B Audio
+is the data file, which can be read or written to use the port.
+Audio data is a sequence of stereo samples, left sample first.
+Each sample is a 16 bit little-endian two's complement integer;
+the default sampling rate is 44.1 kHz.
+Some implementations only support audio output
+and return a zero length when read.
+.PP
+The length of the
+.B audio
+file as returned by
+.IR stat (2)
+represents the number of bytes buffered for input or output.
+This provides some control over record or playback latency.
+.PP
+The file
+.B audiostat
+provides additional timing and latency control.  When read, it returns
+lines of the form
+.br
+.B "bufsize \f2s\fP buffered \f2b\fP offset \f2o\fP time \f2t\fP
+.br
+reporting number of bytes
+.I s
+used for DMA operations (i.e., the minimum useful size for reads and writes),
+the number of bytes
+.I b
+currently buffered, and the time
+.I t
+at which offset
+.I o
+was reached.  Using
+.I t
+and
+.IR o ,
+it is possible to calculate at what time a byte with a different offset will
+be recorded or played back.  See also
+.IR usb (4).
+.PP
+.B Volume
+is the control file associated with the audio port.
+Each input and output source has an associated stereo volume control,
+ranging from 0 (quiet) to 100 (loud).
+In addition, there are controls for the sampling rate of the D/A and A/D converters
+and for any tone controls.
+Reads
+return lines of the form
+.IP
+.I source
+.B in left
+.I value 
+.B right
+.I value
+.B out left
+.I value
+.B right
+.I value
+.PP
+possibly abbreviated if the values are shared or non-existent.
+For example, if all of the values are shared, the form degenerates to
+.RI ` source
+.IR value '.
+Valid sources depend on the particular audio device,
+though all devices have a
+.B audio
+stereo source, which controls the output volume from the D/A converter
+connected to
+.BR audio .
+.PP
+Writes accept the same format with same abbreviations.
+Writing the string
+.B reset
+sets all of the attributes to their default value,
+and if no attribute is supplied,
+.B audio
+is assumed.
+.PP
+The Sound Blaster 16 (or MCD) is half-duplex and accepts the following controls on its
+.B volume
+file,
+in the format shown above for reads.
+.TP
+.B audio out
+Data written to audio.
+.TP
+.B synth in out
+MIDI synthesizer.
+.TP
+.B cd in out
+CD player.
+.TP
+.B line in out
+Line-level input.
+.TP
+.B mic in out
+Monaural microphone input.
+.TP
+.B speaker in out
+Monaural internal speaker connection.
+.TP
+.B treb out
+Stereo treble tone control.
+Values less than 50 decrease the treble,
+those greater increase it.
+.TP
+.B bass out
+Stereo bass tone control.
+.TP
+.B speed in out
+Sampling rate for the D/A and A/D converters,
+expressed in Hz.
+Defaults to 44100.
+.PP
+.SH SOURCE
+.B /sys/src/9/port/devaudio.c
diff --git a/static/plan9-4e/man3/cap.3 b/static/plan9-4e/man3/cap.3
new file mode 100644
index 00000000..5d6bffba
--- /dev/null
+++ b/static/plan9-4e/man3/cap.3
@@ -0,0 +1,81 @@
+.TH CAP 3 
+.SH NAME
+cap \- capabilities for setting the user id of processes
+.SH SYNOPSIS
+.B bind #¤
+.I dir
+.nf
+
+.IB dir /caphash
+.IB dir /capuse
+.fi
+.SH DESCRIPTION
+.PP
+This device enables a trusted process to
+create a capability that another process
+may then use to change its user id.  The intent is to allow
+server processes, for example
+.B telnetd
+(see
+.IR ipserv (8)),
+to change their user id after having proved
+to a trusted process, such as
+.IR factotum (4),
+that they are indeed executing
+on behalf of a user.
+A trusted process is one running with the user id
+of the host owner (see
+.B /dev/hostowner
+in
+.IR cons (3)).
+.PP
+A capability is a null terminated string consisting of the concatenation of
+an old user name, an ``@'', a new user name, an ``@'', and a string of randomly
+generated characters called the key.
+The trusted process enables the kernel to authenticate
+capabilities passed to it by writing to
+.I caphash
+a secure hash of the capability.
+The hash is 20 bytes long and generated by the following call:
+.EX
+
+	hmac_sha1(old_at_new, strlen(old_at_new), key, strlen(key),
+		hash, nil);
+
+.EE
+The kernel maintains a list of hashes, freeing them after the
+corresponding capability is used or after a minute has passed
+since the write to
+.IR caphash .
+.PP
+The trusted process may then pass the capability to any process
+running as the old user.  That process may then
+use the capability to change identity to the new user.
+A process uses a capability by writing it to
+.IR capuse .
+The kernel computes the same hash using the supplied capability
+and searches its list of hashes for a match.  If one is found,
+the kernel sets the process's user id to that in the capability.
+.SH DIAGNOSTICS
+.PP
+Errors generated by reading and writing
+.I caphash
+and
+.I capuse
+can be obtained using
+.IR errstr (2).
+A read of
+.I caphash
+with a length of less than 20
+or a write to
+.I capuse
+that doesn't contain two @ characters
+generates the error ``read or write too small''.
+A write to
+.I capuse
+that has no matching hash generates the error
+``invalid capability''.
+.SH SOURCE
+.B /sys/src/9/port/devcap.c
+.SH "SEE ALSO"
+.IR sechash (2)
diff --git a/static/plan9-4e/man3/cons.3 b/static/plan9-4e/man3/cons.3
new file mode 100644
index 00000000..0d4de988
--- /dev/null
+++ b/static/plan9-4e/man3/cons.3
@@ -0,0 +1,346 @@
+.TH CONS 3 
+.SH NAME
+cons \- console, clocks, process/process group ids, user, null, reboot, etc.
+.SH SYNOPSIS
+.nf
+.B bind #c /dev
+
+.B /dev/bintime
+.B /dev/cons
+.B /dev/consctl
+.B /dev/cputime
+.B /dev/drivers
+.B /dev/hostdomain
+.B /dev/hostowner
+.B /dev/kprint
+.B /dev/null
+.B /dev/osversion
+.B /dev/pgrpid
+.B /dev/pid
+.B /dev/ppid
+.B /dev/random
+.B /dev/reboot
+.B /dev/swap
+.B /dev/sysname
+.B /dev/sysstat
+.B /dev/time
+.B /dev/user
+.B /dev/zero
+.fi
+.SH DESCRIPTION
+The console device serves a one-level directory
+giving access to the console and
+miscellaneous information.
+.PP
+Reading the
+.B cons
+file returns characters typed on the keyboard.
+Normally, characters are buffered to enable erase and kill processing.
+A control-U,
+.LR ^U ,
+typed at the keyboard
+.I kills
+the current input line (removes all characters
+from the buffer of characters
+not yet read via
+.BR cons ),
+and a backspace
+.I erases
+the previous non-kill, non-erase character from the input buffer.
+Killing and erasing only delete characters back to, but not including,
+the last newline.
+Characters typed at the keyboard actually produce 16-bit runes (see
+.IR utf (6)),
+but the runes are translated into the variable-length
+.SM UTF
+encoding (see
+.IR utf (6))
+before putting them into the buffer.
+A
+.IR read (2)
+of length greater than zero causes the process to wait until a
+newline or a
+.L ^D
+ends the buffer, and then returns as much of the buffer as the argument
+to
+.B read
+allows, but only up to one complete line.
+A terminating
+.L ^D
+is not put into the buffer.
+If part of the line remains, the next
+.B read
+will return bytes from that remainder and not part of any new line
+that has been typed since.
+.PP
+If
+the string
+.B rawon
+has been written to the
+.B consctl
+file and the file is still open,
+.B cons
+is in
+.IR "raw mode" :
+characters are not echoed as they are typed,
+backspace and
+.L ^D
+are not treated specially,
+and characters are available to
+.I read
+as soon as they are typed.
+Ordinary mode is reentered when
+.B rawoff
+is written to
+.B consctl
+or this file is closed.
+.PP
+A
+.I write
+(see
+.IR read (2))
+to
+.B cons
+causes the characters to be printed on the console screen.
+.PP
+The
+.B osversion
+file contains a textual representation of the operating system's version and parameters.
+At the moment, it contains one field: the 9P protocol version, currently
+.BR 2000 .
+.PP
+The
+.B kprint
+file may be read to receive a copy of the data written
+to the console by the kernel's print statements or by processes
+writing to
+.BR /dev/cons .
+Only data written after the file is opened is available.
+If the machine's console is a serial line, the data is sent both to the
+console and to
+.BR kprint ;
+if its console is a graphics screen, the data is sent either to the
+display or to
+.BR kprint ,
+but not both.
+(It is advisable not to open
+.B kprint
+on terminals until you have started
+.IR rio (1).)
+.PP
+The
+.B null
+file throws away anything written to it
+and always returns zero bytes when read.
+.PP
+The
+.B zero
+file is a read-only file that produces an infinite stream of zero-valued bytes when read.
+.PP
+The
+.B drivers
+file contains, one per line, a listing of the drivers configured in the kernel, in the format
+.IP
+.EX
+#c cons
+.EE
+.PP
+The
+.B hostdomain
+file contains the name of the authentication domain that
+this host belongs to; see
+.IR authsrv (6).
+Only the user named in
+.B /dev/hostowner
+may write this.
+.PP
+The
+.B hostowner
+file contains the name of the user that owns the console device files.
+The hostowner also has group permissions for any local devices.
+.PP
+Reads from
+.B random
+return a stream of random numbers.  The numbers are
+generated by a low priority kernel process that loops
+incrementing a variable.  Each clock tick the variable
+is sampled and, if it has changed sufficiently, the last
+few bits are appended to a buffer.  This process is inefficient
+at best producing at most a few hundred bits a second.
+Therefore,
+.B random
+should be treated as a seed to
+pseudo-random number generators which can produce a faster
+rate stream.
+.PP
+Writing the string
+.B reboot
+to
+.B reboot
+causes the system to shutdown and, if
+possible, restart.
+Writing the string
+.B reboot
+.I kernelpath
+loads the named kernel image and restarts,
+preserving the kernel configuration in
+.BR #ec ,
+except that the
+.B bootfile
+variable is set to
+.IR kernelpath .
+Only the host
+owner has the ability to open this file.
+.PP
+.B Bintime
+is a binary interface that provides
+the same information as
+.B time
+.RI ( q.v. ),
+in binary form,
+and also controls clock frequency and clock trim.
+All integers read or written from
+.B bintime
+are in big endian order.
+Unlike the other files, reads and writes do not affect
+the offset.  Therefore, there is no need for a seek
+back to zero between subsequent accesses.
+A read of
+.B bintime
+returns 24 bytes, three 8 byte numbers, representing nanoseconds
+since start of epoch, clock ticks, and clock frequency.
+.PP
+A write to
+.B bintime
+is a message with one of 3 formats:
+.IP "\f5n\fP<8-byte \f2time\fP>" 1.2i
+set the nanoseconds since epoch to the given
+.IR time .
+.IP "\f5d\fP<8-byte \f2delta\fP><4-byte \f2period\fP>" 1.2i
+trim the nanoseconds since epoch by
+.I delta
+over the next
+.I period
+seconds.
+.IP "\f5f\fP<8-byte \f2freq\fP>" 1.2i
+Set the frequency for interpreting clock ticks to be
+.I freq
+ticks per second.
+.PP
+The rest of the files contain (mostly) read-only strings.
+Each string has a fixed length: a
+.IR read (2)
+of more than that gives a result of that fixed length (the result does not
+include a terminating zero byte);
+a
+.I read
+of less than that length leaves the file offset so the
+rest of the string (but no more) will be read the next time.
+To reread the file without closing it,
+.I seek
+must be used to reset the offset.
+When the file contains numeric data
+each number is formatted in decimal.
+If the binary number fits in 32 bits, it is formatted as an
+11 digit decimal number with
+leading blanks and one trailing blank; totaling 12 bytes.
+Otherwise, it
+is formatted as 21 digit decimal numbers with leading blanks and one
+trailing blank; totaling 22 bytes.  
+.PP
+The
+.B cputime
+file holds six 32-bit numbers, containing the time in milliseconds
+that the current process has spent in user mode, system calls,
+real elapsed time, and then the time spent, by exited children and their descendants,
+in user mode, system calls, and real elapsed time.
+.PP
+The
+.B time
+file holds one 32-bit number representing the seconds since start of epoch
+and three 64-bit numbers, representing nanoseconds since
+start of epoch, clock ticks, and clock frequency.
+.PP
+A write of a decimal number to
+.B time
+will set the seconds since epoch.
+.PP
+The
+.B sysname
+file holds the textual name of the machine, e.g.
+.BR kremvax ,
+if known.
+.PP
+The
+.B sysstat
+file holds 8 numbers:
+processor number, context switches, interrupts, system calls, page faults,
+TLB faults, TLB purges, and load average.
+The load average is in units of milli-CPUs and is decayed over time;
+the others are total counts from boot time.
+If the machine is a multiprocessor,
+.B sysstat
+holds one line per processor.
+Writing anything to
+.B sysstat
+resets all of the counts on all processors.
+.PP
+The
+.B swap
+device holds a string of the form
+.IP
+.IB m1 / m2
+.B memory
+.IB s1 / s2
+.B swap
+.PP
+These give, for each of
+internal memory and the swapping area,
+the number of pages used and the total available.
+These numbers are not blank padded.
+To turn on swapping, write to
+.B swap
+the textual file descriptor number of a file or device on which to swap.
+See
+.IR swap (8).
+.PP
+The other files served by the
+.I cons
+device are all single numbers:
+.TP 10
+.B pgrpid
+process group number
+.TP
+.B pid
+process number
+.TP
+.B ppid
+parent's process number
+.SH SEE ALSO
+.IR draw (3),
+.IR keyboard (6),
+.IR authsrv (6),
+.IR utf (6),
+.IR swap (8)
+.SH SOURCE
+.B /sys/src/9/port/devcons.c
+.SH BUGS
+For debugging, two control-T's followed by a letter
+generate console output and manage debugging:
+.L ^T^Td
+toggles whether the console debugger will be run if the system fails.
+.L ^T^TD
+starts the console debugger immediately.
+.L ^T^Tk
+kills the largest process; use with care.
+.L ^T^Tp
+prints data about processes.
+.L ^T^Tq
+prints the run queue for processor 0.
+.L ^T^Ts
+prints the kernel stack.
+.L ^T^Tx
+prints data about kernel memory allocation.
+.PP
+The system can be rebooted by typing
+.LR ^T^Tr .
diff --git a/static/plan9-4e/man3/draw.3 b/static/plan9-4e/man3/draw.3
new file mode 100644
index 00000000..89a6c196
--- /dev/null
+++ b/static/plan9-4e/man3/draw.3
@@ -0,0 +1,782 @@
+.TH DRAW 3 
+.SH NAME
+draw \- screen graphics
+.SH SYNOPSIS
+.nf
+.B bind -a #i /dev
+
+.B /dev/draw/new
+
+.BI /dev/draw/ n /ctl
+.BI /dev/draw/ n /data
+.BI /dev/draw/ n /colormap
+.BI /dev/draw/ n /refresh
+
+.ft L
+#include <u.h>
+#include <draw.h>
+
+.ta \w'ushort 'u
+ushort	BGSHORT(uchar *p)
+ulong	BGLONG(uchar *p)
+void	BPSHORT(uchar *p, ushort v)
+void	BPLONG(uchar *p, ulong v)
+.ft P
+.fi
+.SH DESCRIPTION
+The
+.I draw
+device serves a three-level file system 
+providing an interface to the graphics facilities of the system.
+Each client of the device connects by opening
+.B /dev/draw/new
+and reading 12 strings, each 11 characters wide followed by a blank:
+the connection number
+.RI ( n ),
+the image id
+.RI ( q.v. )
+of the display image (always zero),
+the
+channel format
+of the image,
+the
+.BR min.x ,
+.BR min.y ,
+.BR max.x ,
+and
+.B max.y
+of the display image,
+and the
+.BR min.x ,
+.BR min.y ,
+.BR max.x ,
+and
+.B max.y 
+of the clipping rectangle. 
+The channel format string is described in 
+.IR image (6),
+and the other fields are decimal numbers.
+.PP
+The client can then open the directory
+.BI /dev/draw/ n /
+to access the
+.BR ctl ,
+.BR data ,
+.BR colormap ,
+and
+.B refresh
+files associated with the connection.
+.PP
+Via the 
+.B ctl
+and
+.B draw 
+files, the
+.I draw
+device provides access to 
+images and font caches
+in its private storage,
+as described in 
+.IR graphics (2).
+Each image is identified by a 4-byte integer, its
+.IR id .
+.PP
+Reading the
+.B ctl 
+file yields 12 strings formatted as in
+.BR /dev/draw/new ,
+but for the current image rather
+than the display image.
+The current image may be set by writing a
+binary image id to the
+.B ctl
+file.
+.PP
+A process can write messages to 
+.B data
+to allocate and free images, fonts, and subfonts;
+read or write portions of the images;
+and draw line segments and character
+strings in the images.
+All graphics requests are clipped to their images.
+Some messages return a response to be recovered by 
+reading the
+.B data 
+file.
+.PP
+The format of messages written to
+.B data
+is a single letter
+followed by binary parameters;
+multibyte integers are transmitted with the low order byte first.
+The
+.B BPSHORT
+and
+.B BPLONG
+macros place correctly formatted two- and four-byte integers into a character
+buffer.
+.B BGSHORT
+and
+.B BGLONG
+retrieve values from a character buffer.
+Points are two four-byte numbers:
+.IR x ,
+.IR y .
+Rectangles are four four-byte numbers: min 
+.IR x ,
+min
+.IR y ,
+max
+.IR x ,
+and max
+.IR y .
+Images, screens, and fonts have 32-bit identifiers.
+In the discussion of the protocol below,
+the distinction between identifier and actual image, screen, or font
+is not made, so that
+``the object
+.IR id ''
+should be interpreted as 
+``the object with identifier
+.IR id ''.
+The definitions of constants used in the description below can be found in
+.BR draw.h .
+.PP
+The following requests are accepted by the
+.B data
+file.
+The numbers in brackets give the length in bytes of the parameters.
+.HP .5i
+.B A
+.IR id [4]
+.IR imageid [4]
+.IR fillid [4]
+.IR public [1]
+.br
+Allocate a new
+.B Screen
+(see
+.IR window (2))
+with
+screen identifier
+.I id
+using
+backing store image
+.IR imageid ,
+filling it initially
+with data from image
+.IR fillid .
+If the
+.I public
+byte is non-zero, the screen can 
+be accessed from other processes
+using the
+.B publicscreen
+interface.
+.HP
+.B b 
+.IR id [4]
+.IR screenid [4]
+.IR refresh [1]
+.IR chan [4]
+.IR repl [1]
+.IR r [4*4]
+.IR clipr [4*4]
+.IR color [4]
+.br
+Allocate an image with a given 
+.I id 
+on the
+screen named by
+.IR screenid .
+The image will have rectangle
+.I r 
+and clipping rectangle
+.IR clipr .
+If 
+.I repl
+is non-zero, the image's replicate 
+bit will be set (see
+.IR draw (2)).
+.IP
+.I Refresh
+specifies the method to be used to draw the window
+when it is uncovered.
+.B Refbackup
+causes the server to maintain a backing store,
+.B Refnone 
+does not refresh the image,
+and
+.B Refmesg
+causes a message to be sent via
+the
+.B refresh 
+file
+.RI ( q.v. ).
+.IP
+The image format is described by
+.IR chan ,
+a binary version of the channel format string.
+Specifically, the image format is the catenation of up to four
+8-bit numbers, each describing a particular image channel.
+Each of these 8-bit numbers contains a channel type in its
+high nibble and a bit count in its low nibble.
+The channel type is one of
+.BR CRed ,
+.BR CGreen ,
+.BR CBlue ,
+.BR CGrey ,
+.BR CAlpha ,
+.BR CMap ,
+and
+.BR CIgnore .
+See
+.IR image (6).
+.IP
+.I Color
+is the catenation of four 8-bit numbers
+specifying the red, green, blue, and alpha
+channels of the color that the new image should
+be initially filled with.
+The red channel is in the highest 8 bits, and
+the alpha in the lowest.
+Note that color is always in this format, independent of 
+the image format.
+.HP
+.B c
+.IR dstid [4]
+.IR repl [1]
+.IR clipr [4*4]
+.br
+Change the replicate bit and clipping rectangle of the 
+image
+.IR dstid .
+This overrides whatever settings were specified in
+the allocate message.
+.HP
+.B d
+.IR dstid [4]
+.IR srcid [4]
+.IR maskid [4]
+.IR dstr [4*4]
+.IR srcp [2*4]
+.IR maskp [2*4]
+.br
+Use the 
+.B draw
+operator to combine the rectangle 
+.I dstr
+of 
+image
+.I dstid 
+with a 
+rectangle of image
+.IR srcid ,
+using a rectangle of image
+.IR maskid
+as an alpha mask to further control blending.
+The three rectangles are congruent and aligned such that
+the upper left corner
+.I dstr
+in image
+.I dstid
+corresponds to
+the point 
+.I srcp
+in image
+.I srcid
+and
+the point
+.I maskp
+in image
+.IR maskid .
+See
+.IR draw (2).
+.HP
+.B D
+.IR debugon [1]
+.br
+If
+.I debugon
+is non-zero, enable debugging output.
+If zero, disable it.
+The meaning of ``debugging output'' is implementation dependent.
+.HP
+.B e
+.IR dstid [4]
+.IR srcid [4]
+.IR c [2*4]
+.IR a [4]
+.IR b [4]
+.IR thick [4]
+.IR sp [2*4]
+.IR alpha [4]
+.IR phi [4]
+.br
+Draw an ellipse in image
+.I dst
+centered on the point
+.I c
+with horizontal and vertical semiaxes
+.I a
+and
+.IR b .
+The ellipse is drawn using the image
+.IR src ,
+with
+the point
+.I sp
+in 
+.I src
+aligned with
+.I c
+in
+.IR dst .
+The ellipse is drawn with thickness
+.RI 1+2× thick .
+.IP
+If the high bit of
+.I alpha
+is set, 
+only the arc of the ellipse from degree angles
+.I alpha
+to
+.I phi 
+is drawn.
+For the purposes of drawing the arc,
+.I alpha
+is treated as a signed 31-bit number
+by ignoring its high bit.
+.HP
+.B E
+.IR dstid [4]
+.IR srcid [4]
+.IR center [2*4]
+.IR a [4]
+.IR b [4]
+.IR thick [4]
+.IR sp [2*4]
+.IR alpha [4]
+.IR phi [4]
+.br
+Draws an ellipse or arc as the
+.B e
+message, but rather than outlining it, fills
+the corresponding sector using the image
+.IR srcid .
+The 
+.I thick 
+field is ignored, but must be non-negative.
+.HP
+.B f
+.IR id [4]
+.br
+Free the resources associated with the image
+.IR id .
+.HP
+.B F
+.IR id [4]
+.br
+Free the the screen with the specified
+.IR id .
+Windows on the screen must be freed separately.
+.HP
+.B i
+.IR id [4]
+.IR n [4]
+.IR ascent [1]
+.br
+Treat the image
+.I id
+as a font cache of 
+.I n
+character cells, each with
+ascent
+.IR ascent .
+.HP
+.B l
+.IR cacheid [4]
+.IR srcid [4]
+.IR index [2]
+.IR r [4*4]
+.IR sp [2*4]
+.IR left [1]
+.IR width [1]
+.br
+Load a character into the font cache associated with image
+.I cacheid
+at cache position
+.IR index .
+The character data is drawn in rectangle
+.I r
+of the font cache image
+and is fetched from
+the congruent rectangle in image
+.I srcid
+with upper left corner
+.IR sp .
+.I Width
+specifies the width of the character\(emthe spacing from this character to the next\(emwhile
+.I left
+specifies
+the horizontal distance from the left side
+of the character to the left side of the cache image.
+The dimensions of the image of the character are defined by
+.IR r .
+.HP
+.B L
+.IR dstid [4]
+.IR p0 [2*4]
+.IR p1 [2*4]
+.IR end0 [4]
+.IR end1 [4]
+.IR thick [4]
+.IR srcid [4]
+.IR sp [2*4]
+.br
+Draw a line of thickness
+.RI 1+2× thick
+in image
+.I dstid
+from point
+.I p0
+to
+.IR p1 .
+The line is drawn using the image
+.IR srcid ,
+translated so that point
+.I sp
+in
+.I srcid
+aligns with
+.I p0
+in 
+.IR dstid .
+The 
+.I end0
+and
+.I end1
+fields specify whether the corresponding
+line end should be a square, a disc,
+or an arrow head.
+See 
+.I line
+in
+.IR draw (2)
+for more details.
+.HP
+.B N
+.IR id [4]
+.IR in [1]
+.IR j [1]
+.IR name [ j ]
+.br
+If 
+.I in
+is non-zero, associate the image
+.I id
+with the string
+.IR name .
+If 
+.I in
+is zero and 
+.I name
+already corresponds to the
+image
+.IR id ,
+the association is deleted.
+.HP
+.B n
+.IR id [4]
+.IR j [1]
+.IR name [ j ]
+.br
+Introduce the identifier 
+.I id
+to correspond to the image named
+by the string
+.IR name .
+.HP
+.B o
+.IR id [4]
+.IR r.min [2*4]
+.IR scr [2*4]
+.br
+Position the window 
+.I id
+so that its upper left corner is at the
+point
+.I scr
+on its screen.
+Simultaneously change its internal (logical) coordinate system
+so that the point
+.I log
+corresponds to the upper left corner of the window.
+.HP
+.B p
+.IR dstid [4]
+.IR n [2]
+.IR end0 [4]
+.IR end1 [4]
+.IR thick [4]
+.IR srcid [4]
+.IR sp [2*4]
+.IR dp [2*2*(n+1)]
+.br
+Draw a polygon of thickness
+.RI 1+2× thick .
+It is conceptually equivalent to a series of
+.I n
+line-drawing messages (see
+.B L
+above)
+joining adjacent points in the list of points
+.IR dp .
+The source image
+.I srcid
+is translated so that the point
+.I sp
+in
+.I srcid
+aligns with the first point
+in the list
+.IR dp .
+The polygon need not be closed: 
+.I end0
+and
+.I end1
+specify the line endings for the first and
+last point on the polygon.
+All interior lines have rounded ends
+to make smooth joins.
+.HP
+.B P
+.IR dstid [4]
+.IR n [2]
+.IR wind [4]
+.IR ignore [2*4]
+.IR srcid [4]
+.IR sp [2*4]
+.IR dp [2*2*(n+1)]
+.br
+Draw a polygon as the
+.B p
+message, but
+fill it rather than outlining it.
+The winding rule parameter
+.I wind
+resolves ambiguities about what to fill if the polygon is self-intersecting.
+If
+.I wind
+is
+.BR ~0 ,
+a pixel is inside the polygon if the polygon's winding number about the point
+is non-zero.
+If
+.I wind
+is
+.BR 1 ,
+a pixel is inside if the winding number is odd.
+Complementary values (0 or ~1) cause outside pixels to be filled.
+The meaning of other values is undefined.
+The polygon is closed with a line if necessary.
+.HP
+.B r
+.IR id [4]
+.IR r [4*4]
+.br
+Cause the next read of the
+.B data
+file to return the image pixel data corresponding to the
+rectangle
+.I r
+in image
+.IR id .
+.HP
+.B s
+.IR dstid [4]
+.IR srcid [4]
+.IR fontid [4]
+.IR p [2*4]
+.IR clipr [4*4]
+.IR sp [2*4]
+.IR n [2]
+.IR n*(index [2])
+.br
+Draw in the image
+.I dstid
+the text string specified by the 
+.I n 
+cache
+.I indices
+into font
+.IR fontid ,
+starting with the upper left corner at point
+.I p
+in image
+.IR dstid .
+The image drawn is taken from image
+.IR srcid ,
+translated to align
+.I sp
+in
+.I srcid
+with
+.I dp
+in
+.IR dstid.
+All drawing is confined to the clipping rectangle
+.I clipr 
+in
+.IR dstid .
+.HP
+.B x
+.IR dstid [4]
+.IR srcid [4]
+.IR fontid [4]
+.IR dp [2*4]
+.IR clipr [4*4]
+.IR sp [2*4]
+.IR n [2]
+.IR bgid [4]
+.IR bp [2*4]
+.IR n*(index [2])
+.br
+Like the string drawing 
+.B s
+command, but fill the background of each character
+with pixels from image
+.IR bgid .
+The image
+.I bgid
+is translated so that the point
+.I bp
+aligns with the
+point 
+.I dp
+in 
+.IR dstid .
+.HP
+.B S
+.IR id [4]
+.IR chan [4]
+Attach to the public screen with the specified
+.IR id .
+It is an error if the screen does not exist, is not public, or does not
+have the channel descriptor
+.I chan
+for its associated image.
+.HP
+.B t
+.IR top [1]
+.IR n [2]
+.IR n*id [4]
+.br
+Send 
+.I n
+windows to the top (if
+.I t
+is non-zero) or bottom (if
+.I t
+is zero) of the window stack.
+The window is specified by the list of
+.I n
+image
+.IR id s
+are moved as a group, maintaining their own order within the stack.
+.HP
+.B v
+.br
+Flush changes from a soft screen, if any, to the display buffer.
+.HP
+.B y
+.IR id [4]
+.IR r [4*4]
+.IR buf [x*1]
+.br
+.ti -0.5i
+.B Y
+.IR id [4]
+.IR r [4*4]
+.IR buf [x*1]
+.br
+Replace the rectangle 
+.I r
+of pixels in image
+.I id
+with the pixel data in 
+.IR buf .
+The pixel data must be in the format dictated by
+.IR id 's
+image channel descriptor (see
+.IR image (6)).
+The 
+.B y
+message uses uncompressed data,
+while the
+.B Y
+message uses compressed data. 
+In either case, 
+it is an error to include more data than necessary.
+.PP
+Reading the
+.B colormap
+returns the system color map used on 8-bit displays.
+Each color map entry consists of a single line containing
+four space-separated decimal strings.
+The first is an index into the map, and the remaining three are
+the red, green, and blue values associated with that index.
+The color map can be changed by writing entries in the
+above format to
+the 
+.B colormap
+file.
+Note that changing the system color map 
+does not change the color map used for
+calculations involving
+.B m8
+images, which is immutable.
+.PP
+The
+.B refresh
+file is read-only.
+As windows owned by the client are uncovered,
+if they cannot be refreshed by the server (such as when they have
+refresh functions associated with them), a message is made available
+on the
+.B refresh
+file reporting what needs to be repainted by the client.
+The message has five decimal integers formatted as in the
+.B ctl
+message: the image id of the window and the coordinates of the rectangle
+that should be refreshed.
+.SH SOURCE
+.B /sys/src/9/port/devdraw.c
+.br
+.B /sys/src/libmemdraw
+.SH DIAGNOSTICS
+Most messages to
+.B draw
+can return errors;
+these can be detected by a system call error
+on the
+.IR write (see
+.IR read (2))
+of the data containing the erroneous message.
+The most common error is a failure to allocate
+because of insufficient free resources.  Most other errors occur
+only when the protocol is mishandled by the application.
+.IR Errstr (2)
+will report details.
+.SH BUGS
+The 
+.B Refmesg
+refresh method is not fully implemented.
+.br
+The
+.B colormap
+files only reference the system color map, and as 
+such should be called
+.B /dev/colormap
+rather than
+.BI /dev/draw/ n /colormap\f1.
diff --git a/static/plan9-4e/man3/dup.3 b/static/plan9-4e/man3/dup.3
new file mode 100644
index 00000000..6ce855e9
--- /dev/null
+++ b/static/plan9-4e/man3/dup.3
@@ -0,0 +1,58 @@
+.TH DUP 3 
+.SH NAME
+dup \- dups of open files
+.SH SYNOPSIS
+.nf
+.B bind #d /fd
+
+.B /fd/0
+.B /fd/0ctl
+.B /fd/1
+.B /fd/1ctl
+\&...
+.fi
+.SH DESCRIPTION
+The
+.I dup
+device serves a one-level directory containing files whose
+names are decimal numbers.
+Each such file also has an associated control file.
+A file of name
+.I n
+corresponds to open file descriptor
+.I n
+in the current process.
+.PP
+An
+.IR open (2)
+of file
+.I n
+results in a file descriptor identical to
+what would be returned from a system call
+.IB dup ( n ,
+.BR -1) .
+Note that the result is no longer a file in the
+.I dup
+device.
+.PP
+The
+.I stat
+operation returns information about the device file, not the open file it points to.
+A stat of
+.BI #d/ n
+will contain
+.I n
+for the name, 0 for the length, and 0400, 0200, or 0600
+for the mode, depending on whether the dup target is open
+for reading, writing, or both.
+.PP
+A file of name
+.IB n ctl
+may be read to discover the properties of the associated file descriptor, in format identical to that of the
+.B fd
+file in
+.IR proc (3).
+.SH SEE ALSO
+.IR dup (2)
+.SH SOURCE
+.B /sys/src/9/port/devdup.c
diff --git a/static/plan9-4e/man3/env.3 b/static/plan9-4e/man3/env.3
new file mode 100644
index 00000000..2724f2ac
--- /dev/null
+++ b/static/plan9-4e/man3/env.3
@@ -0,0 +1,64 @@
+.TH ENV 3
+.SH NAME
+env \- environment variables
+.SH SYNOPSIS
+.nf
+.B bind #e /env
+
+.BI /env/ var1
+.BI /env/ var2
+ ...
+.fi
+.SH DESCRIPTION
+The
+.I env
+device serves a one-level directory containing files with arbitrary names
+and contents.
+The intention is that the file name is the name of an
+.I environment variable
+(see
+.IR rc (1)),
+and the content is the variable's current value.
+.PP
+When a
+.IR fork (2)
+system call creates a new process, both the parent and the
+child continue to see exactly the same files in the
+.I env
+device: changes made in either process can be noticed by the other.
+In contrast, an
+.B rfork
+system call with the
+.B RFENVG
+bit set (see
+.IR fork (2))
+causes a split: initially both process groups see the
+same environment files, but any changes made in one process group
+cannot be noticed by the other.
+An
+.B rfork
+with
+.B RFCENVG
+splits and then clears the environment.
+.PP
+The special global environment
+.B #ec
+contains kernel configuration variables,
+such as those set in 
+.IR plan9.ini (8).
+All processes see the same
+.BR #ec ;
+its contents are writable only by the host owner.
+[XXX actually everything is world writable; that's a mistake.]
+.SH SEE ALSO
+.IR rc (1),
+.IR fork (2),
+.B #c/reboot
+in
+.IR cons (3),
+.IR plan9.ini (8)
+.SH SOURCE
+.B /sys/src/9/port/devenv.c
+.SH BUGS
+A write starting at an offset after the current extent of a file
+yields an error instead of zero filling.
diff --git a/static/plan9-4e/man3/ether.3 b/static/plan9-4e/man3/ether.3
new file mode 100644
index 00000000..05aa6c76
--- /dev/null
+++ b/static/plan9-4e/man3/ether.3
@@ -0,0 +1,96 @@
+.TH ETHER 3 
+.SH NAME
+ether \- Ethernet device
+.SH SYNOPSIS
+.nf
+.B bind -a #l /net
+
+.BI /net/ether n /clone
+.BI /net/ether n /[0-7]
+.BI /net/ether n /[0-7]/data
+.BI /net/ether n /[0-7]/ctl
+.BI /net/ether n /[0-7]/ifstats
+.BI /net/ether n /[0-7]/stats
+.BI /net/ether n /[0-7]/type
+
+.fi
+.SH DESCRIPTION
+The Ethernet interface,
+.BI /net/ether n\f1,
+is a directory
+containing subdirectories, one for each distinct Ethernet packet type,
+and a
+.B clone
+file.
+The number
+.I n
+is the device number of the card, permitting multiple cards to be used on a single machine.
+.PP
+Each directory contains files to control the associated connection,
+receive and send data,
+and supply statistics.
+Incoming Ethernet packets are demultiplexed by packet type and passed up
+the corresponding open connection.
+Reading from the
+.B data
+file reads packets of that type arriving from the network.
+A read will terminate at packet boundaries.
+Each write to the
+.B data
+file causes a packet to be sent.
+The Ethernet address of the interface is inserted into
+the packet header as the source address.
+.PP
+A connection is assigned to a packet type by opening its
+.B ctl
+file and
+writing 
+.B connect
+.I n
+where
+.I n
+is a decimal integer constant identifying the Ethernet packet type.
+A type of \-1 enables the connection to receive copies of packets of
+all types.  A type of \-2 enables the connection to receive copies of
+the first 64 bytes of packets of all types.
+If multiple connections are assigned to a given packet type
+a copy of each packet is passed up each connection.
+.PP
+Some interfaces also accept unique options when written to the
+.I ctl
+(or
+.IR clone )
+file; see the description of
+.I wavelan
+in
+.IR plan9.ini (8).
+.PP
+Reading the
+.B ctl
+file returns the decimal index of the associated connection, 0 through 7.
+Reading the
+.B type
+file returns the decimal value of the assigned Ethernet packet type.
+Reading the
+.B stats
+file returns status information such as the Ethernet address of the
+card and general statistics, independent of the interface;
+.B ifstats
+contains device-specific data and statistics about the card.
+.PP
+An interface normally receives only those packets whose 
+destination address is that of the interface or is the
+broadcast address,
+.BR ff:ff:ff:ff:ff:ff .
+The interface can be made to receive all packets on the
+network by writing the string 
+.B promiscuous
+to the
+.B ctl
+file. 
+The interface remains promiscuous until the control file is
+closed.
+The extra packets are passed up connections only of types \-1
+and \-2.
+.SH SOURCE
+.B /sys/src/9/*/devether.c
diff --git a/static/plan9-4e/man3/floppy.3 b/static/plan9-4e/man3/floppy.3
new file mode 100644
index 00000000..f1b35466
--- /dev/null
+++ b/static/plan9-4e/man3/floppy.3
@@ -0,0 +1,54 @@
+.TH FLOPPY 3 
+.SH NAME
+floppy \- floppy disk interface
+.SH SYNOPSIS
+.nf
+.B bind -a #f /dev
+
+.B /dev/fd0disk
+.B /dev/fd0ctl
+.B /dev/fd1disk
+.B /dev/fd1ctl
+.B /dev/fd2disk
+.B /dev/fd2ctl
+.B /dev/fd3disk
+.B /dev/fd3ctl
+.fi
+.SH DESCRIPTION
+.PP
+The floppy disk interface serves a one-level directory giving access to up
+to four floppy disk drives.
+Each drive is represented by a data and control file.
+There are no partitions.
+.PP
+Messages accepted by the
+.B ctl
+file include:
+.TF format
+.TP
+.B eject
+Eject the floppy, if possible.
+.TP
+.B reset
+Reset the drive.
+.TP
+.BI format " type
+Format the floppy.  The
+.I type
+sets the density and
+type of disk to be formatted; see
+.B format
+in
+.IR prep (8).
+.PD
+.PP
+A read of the
+.B ctl
+file returns a string describing the form factor of the disk, one of
+.BR 3½DD ,
+.BR 3½HD ,
+.BR 5¼DD ,
+or
+.BR 5¼HD .
+.SH SOURCE
+.B /sys/src/9/*/devfloppy.c
diff --git a/static/plan9-4e/man3/i82365.3 b/static/plan9-4e/man3/i82365.3
new file mode 100644
index 00000000..d0e90d2a
--- /dev/null
+++ b/static/plan9-4e/man3/i82365.3
@@ -0,0 +1,41 @@
+.TH I82365 3 
+.SH NAME
+i82365 \- Personal Computer Memory Card Interface Association (PCMCIA) device
+.SH SYNOPSIS
+.nf
+.B bind -a #y /dev
+
+.B /dev/pcm0attr
+.B /dev/pcm0ctl
+.B /dev/pcm0mem
+.B /dev/pcm1attr
+.B /dev/pcm1ctl
+.B /dev/pcm1mem
+.fi
+.SH DESCRIPTION
+The
+.I i82365
+driver provides an interface to an Intel
+82365-compatible PCMCIA interface chip.
+This chip supports up to 2 PCMCIA slots, 0
+and 1.
+Reading
+.B pcm[01]attr
+returns the contents of attribute memory.
+Reading or writing
+.B pcm[01]mem
+reads or writes RAM on the card.
+Reading
+.B pcm[01]ctl
+returns the card's status.
+.PP
+This driver must be included to use PCMCIA
+devices such as the NE4100 Ethernet card.
+The individual card drivers make calls to routines
+in the PCMCIA driver.
+.SH SOURCE
+.B /sys/src/9/pc/devi82365.c
+.SH "SEE ALSO"
+.IR plan9.ini (8)
+.SH BUGS
+There is no driver for the Databook PCMCIA interface chip.
diff --git a/static/plan9-4e/man3/ip.3 b/static/plan9-4e/man3/ip.3
new file mode 100644
index 00000000..84be502f
--- /dev/null
+++ b/static/plan9-4e/man3/ip.3
@@ -0,0 +1,926 @@
+.TH IP 3 
+.SH NAME
+ip \- network protocols over IP
+.SH SYNOPSIS
+.nf
+.B bind -a #I\fIspec\fP /net
+
+.B /net/ipifc
+.B /net/ipifc/clone
+.B /net/ipifc/stats
+.BI /net/ipifc/ n 
+.BI /net/ipifc/ n /status
+.BI /net/ipifc/ n /ctl
+\&...
+
+.B /net/arp
+.B /net/log
+.B /net/ndb
+.B /net/iproute
+.B /net/ipselftab
+
+.B /net/esp
+.B /net/gre
+.B /net/icmp
+.B /net/il
+.B /net/ipmux
+.B /net/rudp
+.B /net/tcp
+.B /net/udp
+
+.B /net/tcp/clone
+.B /net/tcp/stats
+.BI /net/tcp/ n 
+.BI /net/tcp/ n /data
+.BI /net/tcp/ n /ctl
+.BI /net/tcp/ n /local
+.BI /net/tcp/ n /remote
+.BI /net/tcp/ n /status
+.BI /net/tcp/ n /listen
+\&...
+.fi
+.SH DESCRIPTION
+The IP device provides the interface to Internet protocol stacks.
+.I Spec
+is an integer from 0 to 15 identifying a stack.
+Each stack is physically independent of all others:
+the only information transfer between them is via programs that
+mount multiple stacks.
+Normally a system uses only one stack.
+However multiple stacks can be used for debugging
+new IP networks or implementing firewalls or proxy
+services.
+.PP
+All addresses used are 16-byte IPv6 addresses.  Though
+we currently implement only IPv4, the IPv6 format is intended to
+prepare the way for an IPv6 implementation.  IPv4 addresses
+are a subset of the IPv6 addresses and both standard
+.SM ASCII
+formats
+are accepted.  In binary, all v4 addresses start with the
+12 bytes:
+.EX
+	00 00 00 00 00 00 00 00 00 00 ff ff
+.EE
+.SS "Configuring interfaces
+.PP
+Each stack may have multiple interfaces and each interface
+may have multiple addresses.
+The
+.B /net/ipifc
+directory contains a
+.B clone
+file, a
+.B stats
+file, and numbered subdirectories for each physical interface.
+.PP
+Opening the
+.B clone
+file reserves an interface.
+The file descriptor returned from the
+.IR open (2)
+will point to the control file,
+.BR ctl ,
+of the newly allocated interface.
+Reading
+.B ctl
+returns a text string representing the number of the interface.
+Writing
+.B ctl
+alters aspects of the interface.
+The possible
+.I ctl
+messages are:
+.TP
+.BI "bind ether " path
+Treat the device mounted at
+.I path
+as an Ethernet medium carrying IP and ARP packets
+and associate it with this interface.
+The kernel will
+.IR dial (2)
+.IR path !0x800
+and
+.IR path !0x806
+and use the two connections for IP and
+ARP respectively.
+.TP
+.B "bind pkt
+Treat this interface as a packet interface.  Assume
+a user program will read and write the
+.I data
+file to receive and transmit IP packets to the kernel.
+This is used by programs such as
+.IR ppp (8)
+to mediate IP packet transfer between the kernel and
+a PPP encoded device.
+.TP
+.BI "bind netdev " path
+Treat this interface as a packet interface.
+The kernel will open
+.I path
+and read and write the resulting file descriptor
+to receive and transmit IP packets.
+.TP
+.BI "bind loopback "
+Treat this interface as a local loopback.  Anything
+written to it will be looped back.
+.TP
+.B "unbind
+Disassociate the physical device from an IP interface.
+.TP
+.BI add\  "local mask remote mtu " proxy
+Add a local IP address to the interface.  The
+.IR mask ,
+.IR remote ,
+.IR mtu ,
+and
+.B proxy
+arguments are all optional.  The default mask is
+the class mask for the local address.  The default
+remote address is
+.I local
+ANDed with
+.IR mask .
+The default mtu is 1514 for Ethernet and 4096 for packet
+media.
+.IR Proxy ,
+if specified, means that this machine should answer
+ARP requests for the remote address.
+.IR Ppp (8)
+does this to make remote machines appear
+to be connected to the local Ethernet.
+.TP
+.BI remove\  "local mask"
+Remove a local IP address from an interface.
+.TP
+.BI mtu\  n
+Set the maximum transfer unit for this device to
+.IR n .
+The mtu is the maximum size of the packet including any
+medium-specific headers.
+.TP
+.BI reassemble
+Reassemble IP fragments before forwarding to this interface
+.TP
+.BI iprouting\  n
+Allow
+.RI ( n is missing
+or non-zero) or disallow
+.RI ( n
+is 0) forwarding packets between this interface and
+others.
+.TP
+.BI addmulti\  addr
+Treat the multicast
+.I addr
+on this interface as a local address.
+.TP
+.BI remmulti\  addr
+Remove the multicast address
+.I addr
+from this interface.
+.PP
+Reading the interface's
+.I status
+file returns information about the interface, one line for each
+local address on that interface.  The first line
+has 9 white-space-separated fields: device, mtu, local address,
+mask, remote or network address, packets in, packets out, input errors,
+output errors.  Each subsequent line contains all but the device and mtu.
+See
+.B readipifc
+in
+.IR ip (2).
+.SS "Routing
+.PP
+The file
+.I iproute
+controls information about IP routing.
+When read, it returns one line per routing entry.
+Each line contains six white-space-separated fields:
+target address, target mask, address of next hop, flags,
+tag, and interface number.
+The entry used for routing an IP packet is the one with
+the longest mask for which destination address ANDed with
+target mask equals the target address.
+The one character flags are:
+.TP
+.B 4
+IPv4 route
+.TP
+.B 6
+IPv6 route
+.TP
+.B i
+local interface
+.TP
+.B b
+broadcast address
+.TP
+.B u
+local unicast address
+.TP
+.B m
+multicast route
+.TP
+.B p
+point-to-point route
+.PP
+The tag is an arbitrary, up to 4 character, string.  It is normally used to
+indicate what routing protocol originated the route.
+.PP
+Writing to
+.B /net/iproute
+changes the route table.  The messages are:
+.TP
+.B flush
+Remove all routes.
+.TP
+.BI tag\  string
+Associate the tag,
+.IR string ,
+with all subsequent routes added via this file descriptor.
+.TP
+.BI add\  "target mask nexthop"
+Add the route to the table.  If one already exists with the
+same target and mask, replace it.
+.TP
+.BI remove\  "target mask"
+Remove a route with a matching target and mask.
+.SS "Address resolution
+.PP
+The file
+.B /net/arp
+controls information about address resolution.
+The kernel automatically updates the ARP information for Ethernet
+interfaces.
+When read, the file returns one line per address containing the
+type of medium, the status of the entry (OK, WAIT), the IP
+address, and the medium address.
+Writing to
+.B /net/arp
+administers the ARP information.  The control messages are:
+.TP
+.B flush
+Remove all entries.
+.TP
+.BI add\  "type IP-addr Media-addr"
+Add an entry or replace an existing one for the
+same IP address.
+.PP
+ARP entries do not time out.  The ARP table is a
+cache with an LRU replacement policy.  The IP stack
+listens for all ARP requests and, if the requester is in
+the table, the entry is updated.
+Also, whenever a new address is configured onto an
+Ethernet, an ARP request is sent to help
+update the table on other systems.
+.PP
+Currently, the only medium type is
+.BR ether .
+.SS "Debugging and stack information
+.PP
+If any process is holding
+.B /net/log
+open, the IP stack queues debugging information to it.
+This is intended primarily for debugging the IP stack.
+The information provided is implementation-defined;
+see the source for details.  Generally, what is returned is error messages
+about bad packets.
+.PP
+Writing to
+.B /net/log
+controls debugging.  The control messages
+are:
+.TP
+.BI set\  arglist
+.I Arglist
+is a space-separated list of items for which to enable debugging.
+The possible items are:
+.BR ppp ,
+.BR ip ,
+.BR fs ,
+.BR tcp ,
+.BR il ,
+.BR icmp ,
+.BR udb ,
+.BR compress ,
+.BR ilmsg ,
+.BR gre ,
+.BR tcpmsg ,
+.BR udpmsg ,
+.BR ipmsg ,
+and
+.BR esp .
+.TP
+.BI clear\  arglist
+.I Arglist
+is a space-separated list of items for which to disable debugging.
+.TP
+.BI only\  addr
+If
+.I addr
+is non-zero, restrict debugging to only those
+packets whose source or destination is that
+address.
+.PP
+The file
+.B /net/ndb
+can be read or written by
+programs.  It is normally used by
+.IR ipconfig (8)
+to leave configuration information for other programs
+such as
+.B dns
+and
+.B cs
+(see
+.IR ndb (8)).
+.B /net/ndb
+may contain up tp 1024 bytes.
+.PP
+The file
+.B /net/ipselftab
+is a read-only file containing all the IP addresses
+considered local.  Each line in the file contains
+three white-space-separated fields: IP address, usage count,
+and flags.  The usage count is the number of interfaces to which
+the address applies.  The flags are the same as for routing
+entries.
+.SS "Protocol directories
+.PP
+The
+.I ip
+device
+supports IP as well as several protocols that run over it:
+TCP, IL, UDP, GRE, ESP, ICMP, and RUDP.
+TCP and UDP provide the standard Internet
+protocols for reliable stream and unreliable datagram
+communication.
+IL provides a reliable datagram service for communication
+between Plan 9 machines.
+GRE is a general encapsulation protocol.
+ESP is the encapsulation protocol for IPSEC.
+ICMP is IP's catch-all control protocol used to send
+low level error messages and to implement
+.IR ping (8).
+RUDP is a locally developed reliable datagram protocol based on
+UDP.
+.PP
+Each protocol is a subdirectory of the IP stack.
+The top level directory of each protocol contains a
+.B clone
+file, a
+.B stats
+file, and subdirectories numbered from zero to the number of connections
+opened for this protocol.
+.PP
+Opening the
+.B clone
+file reserves a connection.  The file descriptor returned from the
+.IR open (2)
+will point to the control file,
+.BR ctl ,
+of the newly allocated connection.
+Reading
+.B ctl
+returns a text
+string representing the number of the
+connection.
+Connections may be used either to listen for incoming calls
+or to initiate calls to other machines.
+.PP
+A connection is controlled by writing text strings to the associated
+.B ctl
+file.
+After a connection has been established data may be read from
+and written to
+.BR data .
+A connection can be actively established using the
+.B connect
+message (see also
+.IR dial (2)).
+A connection can be established passively by first
+using an
+.B announce
+message (see
+.IR dial (2))
+to bind to a local port and then
+opening the
+.B listen
+file (see
+.IR dial (2))
+to receive incoming calls.
+.PP
+The following control messages are supported:
+.TP
+.BI connect\  ipaddress ! port "!r " local
+Establish a connection to the remote address
+.I ipaddress
+and remote port
+.IR port .
+If
+.I local
+is specified, it is used as the local port number.
+If
+.I local
+is not specified but
+.B !r
+is, the system will allocate
+a restricted port number (less than 1024) for the connection to allow communication
+with Unix  
+.B login
+and
+.B exec
+services.
+Otherwise a free port number starting at 5000 is chosen.
+The connect fails if the combination of local and remote address/port pairs
+are already assigned to another port.
+.TP
+.BI announce\  X
+.I X
+is a decimal port number or
+.LR * .
+Set the local port
+number to
+.I X
+and accept calls to
+.IR X .
+If
+.I X
+is
+.LR * ,
+accept
+calls for any port that no process has explicitly announced.
+The local IP address cannot be set.
+.B Announce
+fails if the connection is already announced or connected.
+.TP
+.BI bind\  X
+.I X
+is a decimal port number or
+.LR * .
+Set the local port number to
+.IR X .
+This exists to support emulation
+of BSD sockets by the APE libraries (see
+.IR pcc (1))
+and is not otherwise used.
+.TP
+.BI backlog\  n
+Set the maximum number of unanswered (queued) incoming
+connections to an announced port to
+.IR n .
+By default
+.I n
+is set to five.  If more than
+.I n
+connections are pending,
+further requests for a service will be rejected.
+.TP
+.BI ttl\  n
+Set the time to live IP field in outgoing packets to
+.IR n .
+.TP
+.BI tos\  n
+Set the service type IP field in outgoing packets to
+.IR n .
+.PP
+Port numbers must be in the range 1 to 32767.
+.PP
+Several files report the status of a
+connection.
+The
+.B remote
+and
+.B local
+files contain the IP address and port number for the remote and local side of the
+connection.  The
+.B status
+file contains protocol-dependent information to help debug network connections.
+On receiving and error or EOF reading or writing the
+.B data
+file, the
+.B err
+file contains the reason for error.
+.PP
+A process may accept incoming connections by
+.IR open (2)ing
+the
+.B listen
+file.
+The
+.B open
+will block until a new connection request arrives.
+Then
+.B open
+will return an open file descriptor which points to the control file of the
+newly accepted connection.
+This procedure will accept all calls for the
+given protocol.
+See
+.IR dial (2).
+.SS TCP
+.PP
+TCP connections are reliable point-to-point byte streams; there are no
+message delimiters.
+A connection is determined by the address and port numbers of the two
+ends.
+TCP 
+.B ctl
+files support the following additional messages:
+.TP
+.B hangup
+close down a TCP connection
+.TP
+.BI keepalive \ n
+turn on keep alive messages.
+.IR N ,
+if given, is the milliseconds between keepalives
+(default 30000).
+.SS UDP
+.PP
+UDP connections carry unreliable and unordered datagrams.  A read from
+.B data
+will return the next datagram, discarding anything
+that doesn't fit in the read buffer.
+A write is sent as a single datagram.
+.PP
+By default, a UDP connection is a point-to-point link.
+Either a
+.B connect
+establishes a local and remote address/port pair or
+after an
+.BR announce ,
+each datagram coming from a different remote address/port pair
+establishes a new incoming connection.
+However, many-to-one semantics is also possible.
+.PP
+If, after an
+.BR announce ,
+one of the following messages is written to
+.BR ctl ,
+then all messages sent to the announced port
+are received on the announced connection prefixed with the given structure.
+.TP
+.B headers4
+.EX
+typedef struct Udphdr4 Udphdr4;
+struct Udphdr
+{
+	uchar	raddr[4];		/* v4 remote address and port */
+	uchar	laddr[4];		/* v4 local address and port */
+	uchar	rport[2];
+	uchar	lport[2];
+};
+.EE
+.TP
+.B headers
+.EX
+typedef struct Udphdr Udphdr;
+struct Udphdr
+{
+	uchar	raddr[16];	/* v6 remote address and port */
+	uchar	laddr[16];	/* v6 local address and port */
+	uchar	rport[2];
+	uchar	lport[2];
+};
+.EE
+.PP
+The only difference in the two is the type of address, IPv4 or IPv6.
+Before a write, a user must prefix a similar structure to each message.
+The system overrides the user specified local port with the announced
+one.  If the user specifies an address that isn't a unicast address in
+.BR /net/ipselftab ,
+that too is overridden.
+Since the prefixed structure is the same in read and write, it is relatively
+easy to write a server that responds to client requests by just copying new
+data into the message body and then writing back the same buffer that was
+written.
+.SS RUDP
+.PP
+RUDP is a reliable datagram protocol based on UDP.
+Packets are delivered in order.
+RUDP does not support
+.BR listen .
+One must use either
+.B connect
+or
+.B announce
+followed immediately by
+.B headers
+or
+.BR headers4 .
+.PP
+Unlike IL or TCP, the reboot of one end of a connection does
+not force a closing of the connection.  Communications will
+resume when the rebooted machine resumes talking.  Any unacknowledged
+packets queued before the reboot will be lost.  A reboot can
+be detected by reading the
+.B err
+file.  It will have the message
+.IP
+.BI hangup\  address ! port
+.PP
+where
+.I address
+and
+.I port
+are of the far side of the connection.
+Retransmitting a datagram more than 10 times
+is treated like a reboot:
+all queued messages are dropped, an error is queued to the
+.B err
+file, and the conversation resumes.
+.SS IL
+.PP
+IL is a reliable point-to-point datagram protocol.  Like TCP, IL delivers datagrams
+reliably and in order. Also like TCP, a connection is
+determined by the address and port numbers of the two ends.
+Like UDP, each read and write transfers a single datagram.
+.PP
+IL is efficient for LANs but doesn't have the
+congestion control features needed for use through
+the Internet.
+.SS GRE
+.PP
+GRE is the encapsulation protocol used by PPTP.
+The kernel implements just enough of the protocol
+to multiplex it.
+.B Announce
+is not allowed in GRE, only
+.BR connect .
+Since GRE has no port numbers, the port number in the connect
+is actually the 16 bit
+.B eproto
+field in the GRE header.
+.PP
+Reads and writes transfer a
+GRE datagram starting at the GRE header.
+On write, the kernel fills in the
+.B eproto
+field with the port number specified
+in the connect message.
+.SS ESP
+.PP
+ESP is the Encapsulating Security Payload (RFC 1827).
+It is used to set up an encrypted tunnel between machines.
+Like GRE, ESP has no port numbers.  Instead, the
+port number in the
+.B connect
+message is the SPI (Security Association Identifier (sic)).
+IP packets are written to and read from
+.BR data .
+The kernel encrypts any packets written to
+.BR data ,
+appends a MAC, and prefixes an ESP header before
+sending to the other end of the tunnel.
+Received packets are checked against their MAC's,
+decrypted, and queued for reading from
+.BR data .
+The control messages are:
+.TP
+.BI esp\  "alg secret
+Encrypt with the algorithm,
+.IR alg ,
+using
+.I secret
+as the key.
+Possible algorithms are:
+.BR null ,
+.BR des_56_cbc ,
+and
+.BR rc4_128 .
+.TP
+.BI ah\  "alg secret
+Use the hash algorithm,
+.IR alg ,
+with
+.I secret
+as the key for generating the MAC.
+Possible algorithms are:
+.BR null ,
+.BR hmac_sha1_96 ,
+and
+.BR hmac_md5_96 .
+.TP
+.B header
+Turn on header mode.  Every buffer read from
+.B data
+starts with 4 unsued bytes, and the first 4 bytes
+of every buffer written to
+.B data
+are ignored.
+.TP
+.B noheader
+Turn off header mode.
+.SS "IP packet filter
+.PP
+The directory
+.B /net/ipmux
+looks like another protocol directory.
+It is a packet filter built on top of IP.  Each numbered
+subdirectory represents a different filter.
+The connect messages written to the
+.I ctl
+file describe the filter. Packets matching the filter can be read on the
+.B data
+file.  Packets written to the
+.B data
+file are routed to an interface and transmitted.
+.PP
+A filter is a semicolon-separated list of
+relations.  Each relation describes a portion
+of a packet to match.  The possible relations are:
+.TP
+.BI proto= n
+the IP protocol number must be
+.IR n .
+.TP
+.BI dat[ n : m ]= expr
+bytes
+.I n
+through
+.I m
+following the IP packet must match
+.IR expr .
+.TP
+.BI ifc= expr
+the packet must have been received on an interface whose address
+matches
+.IR expr .
+.TP
+.BI src= expr
+The source address in the packet must match
+.IR expr .
+.TP
+.BI dst= expr
+The destination address in the packet must match
+.IR expr .
+.PP
+.I Expr
+is of the form:
+.TP
+.I \	value
+.TP
+.IB \	value | value | ...
+.TP
+.IB \	value & mask
+.TP
+.IB \	value | value & mask
+.PP
+If a mask is given, the relevant field is first ANDed with
+the mask.  The result is compared against the value or list
+of values for a match.  In the case of
+.BR ifc ,
+.BR dst ,
+and
+.B src
+the value is a dot-formatted IP address and the mask is a dot-formatted
+IP mask.  In the case of
+.BR dat ,
+both value and mask are strings of 2 character hexadecimal digits representing
+8 bit values.
+.PP
+A packet is delivered to only one filter.
+The filters are merged into a single comparison tree.
+If two filters match the same packet, the following
+rules apply in order (here '>' means is preferred to):
+.IP 1)
+protocol > data > source > destination > interface
+.IP 2)
+lower data offsets > higher data offsets
+.IP 3)
+longer matches > shorter matches
+.IP 4)
+older > younger
+.PP
+So far this has just been used to implement a version of
+OSPF in Inferno.
+.SS Statistics
+.PP
+The
+.B stats
+files are read only and contain statistics useful to network
+monitoring.
+.PP
+Reading
+.B /net/ipifc/stats
+returns a list of 19 tagged and new line separated fields representing:
+.EX
+.ft 1
+	forwarding status (0 and 2 mean forwarding off, 1 means on)
+	default TTL
+	input packets
+	input header errors
+	input address errors
+	packets forwarded
+	input packets for unknown protocols
+	input packets discarded
+	input packets delivered to higher level protocols
+	output packets
+	output packets discarded
+	output packets with no route
+	timed out fragments in reassembly queue
+	requested reassemblies
+	successful reassemblies
+	failed reassemblies
+	successful fragmentations
+	unsuccessful fragmentations
+	fragments created
+.ft
+.EE
+.PP
+Reading
+.B /net/icmp/stats
+returns a list of 25 tagged and new line separated fields representing:
+.EX
+.ft 1
+	messages received 
+	bad received messages
+	unreachables received
+	time exceededs received
+	input parameter problems received
+	source quenches received
+	redirects received
+	echo requests received
+	echo replies received
+	timestamps received
+	timestamp replies received
+	address mask requests received
+	address mask replies received
+	messages sent
+	transmission errors
+	unreachables sent
+	time exceededs sent
+	input parameter problems sent
+	source quenches sent
+	redirects sent
+	echo requests sent
+	echo replies sent
+	timestamps sent
+	timestamp replies sent
+	address mask requests sent
+	address mask replies sent
+.EE
+.PP
+Reading
+.B /net/tcp/stats
+returns a list of 11 tagged and new line separated fields representing:
+.EX
+.ft 1
+	maximum number of connections
+	total outgoing calls
+	total incoming calls
+	number of established connections to be reset
+	number of currently established connections
+	segments received
+	segments sent
+	segments retransmitted
+	retransmit timeouts
+	bad received segments
+	transmission failures
+.EE
+.PP
+Reading
+.B /net/udp/stats
+returns a list of 4 tagged and new line separated fields representing:
+.EX
+.ft 1
+	datagrams received
+	datagrams received for bad ports
+	malformed datagrams received
+	datagrams sent
+.EE
+.PP
+Reading
+.B /net/il/stats
+returns a list of 7 tagged and new line separated fields representing:
+.EX
+.ft 1
+	checksum errors
+	header length errors
+	out of order messages
+	retransmitted messages
+	duplicate messages
+	duplicate bytes
+.EE
+.PP
+Reading
+.B /net/gre/stats
+returns a list of 1 tagged number representing:
+.EX
+.ft 1
+	header length errors
+.EE
+.SH "SEE ALSO"
+.IR listen (8),
+.IR dial (2),
+.IR ndb (6)
+.SH SOURCE
+.B /sys/src/9/ip
+.SH BUGS
+.I Ipmux
+has not been heavily used and should be considered experimental.
+It may disappear in favor of a more traditional packet filter in the future.
diff --git a/static/plan9-4e/man3/kprof.3 b/static/plan9-4e/man3/kprof.3
new file mode 100644
index 00000000..4d3f9999
--- /dev/null
+++ b/static/plan9-4e/man3/kprof.3
@@ -0,0 +1,66 @@
+.TH KPROF 3 
+.SH NAME
+kprof \- kernel profiling
+.SH SYNOPSIS
+.nf
+.B bind -a #K /dev
+.sp
+.B /dev/kpctl
+.B /dev/kpdata
+.fi
+.SH DESCRIPTION
+The
+.I kprof
+device provides simple profiling
+data for the operating system kernel.   The data accumulates by
+recording the program counter of the kernel at each `tick' of the
+system clock.
+.PP
+The file
+.B kpdata
+holds the accumulated counts as 4-byte integers in big-endian
+byte order.
+The size of the file depends on the size of kernel text.
+The first count
+holds the total number of clock ticks during profiling;
+the second the number of ticks that occurred while the kernel
+was running.  The rest each hold the number of ticks
+the kernel program counter was within the
+corresponding 8-byte range of kernel text, starting from the base
+of kernel text.
+.PP
+The file
+.B kpctl
+controls profiling.
+Writing the string
+.B start
+to
+.B kpctl
+begins profiling;
+.B stop
+terminates it.  The message
+.B startclr
+restarts profiling after zeroing the array of counts.
+.PP
+The program
+.I kprof
+(see
+.IR prof (1))
+formats the data for presentation.
+.SH EXAMPLE
+The following
+.IR rc (1)
+script runs a test program while profiling the kernel
+and reports the results.
+.sp
+.EX
+	bind -a '#K' /dev
+	echo start > /dev/kpctl
+	runtest
+	echo stop > /dev/kpctl
+	kprof /386/9pcdisk /dev/kpdata
+.EE
+.SH SOURCE
+.B /sys/src/9/port/devkprof.c
+.SH SEE ALSO
+.IR prof (1)
diff --git a/static/plan9-4e/man3/loopback.3 b/static/plan9-4e/man3/loopback.3
new file mode 100644
index 00000000..066827a7
--- /dev/null
+++ b/static/plan9-4e/man3/loopback.3
@@ -0,0 +1,88 @@
+.TH LOOPBACK 3 
+.SH NAME
+loopback \- network link simulation
+.SH SYNOPSIS
+.nf
+.B bind -a #X /net
+
+.BI /net/loopback n /[0-1]
+.BI /net/loopback n /[0-1]/data
+.BI /net/loopback n /[0-1]/ctl
+.BI /net/loopback n /[0-1]/status
+.BI /net/loopback n /[0-1]/stats
+
+.fi
+.SH DESCRIPTION
+The loopback interface,
+.BI /net/loopback n\f1,
+is a directory containing two subdirectories,
+one for each end of a simulated network link.
+The number
+.I n
+is the device number of the link, permitting multiple links to be used on a single machine.
+.PP
+Each directory contains files to control the associated connection,
+receive and send data,
+monitor the simulation parameters,
+and supply statistics.
+.PP
+The
+.B data
+files for the two directories are cross-connected.
+Writes to one are divided into packets of at most a certain size,
+typically 32768 bytes,
+written to a flow-controlled output queue,
+transferred across the link,
+and put into an input queue where it is readable from the other
+.B data
+file.
+.PP
+Options are set by writing to the
+.B ctl
+file for the receiving end of the link,
+and are reported in the same format by reading
+.BR status .
+The following options are supported.
+.TP
+.BI delay \ latency\ bytedelay
+Control the time a packet takes in the link.
+A packet
+.B n
+bytes long takes
+.I bytedelay
+.B *
+.B n
+nanoseconds to exit the output queue and
+is available for reading
+.I latency
+nanoseconds later.
+.TP
+.BI droprate \ n
+Randomly drop approximately one out of
+.B n
+packets.
+If zero drop no packets.
+.TP
+.BR indrop \ [01]
+Disallow or allow packets to be dropped if the input queue overflows.
+.TP
+.BI limit \ n
+Set the input and output queues to hold at most
+.I n
+bytes.
+.TP
+.B reset
+Clear all of the statistics recorded for the link.
+.PP
+Reading
+.B stats
+returns a list of 4 tagged numbers representing:
+.EX
+.ft 1
+	packets sent to this receiver
+	bytes sent to this receiver
+	packets dropped due to droprate
+	packets dropped due to input queue overflows
+.EE
+.SH SOURCE
+.B /sys/src/9/port/devloopback.c
diff --git a/static/plan9-4e/man3/lpt.3 b/static/plan9-4e/man3/lpt.3
new file mode 100644
index 00000000..a8df37dd
--- /dev/null
+++ b/static/plan9-4e/man3/lpt.3
@@ -0,0 +1,43 @@
+.TH LPT 3 
+.SH NAME
+lpt \- parallel port interface for PC's
+.SH SYNOPSIS
+.nf
+.B bind -a #L[123] /dev
+
+.B /dev/lpt[123]data
+.B /dev/lpt[123]dlr
+.B /dev/lpt[123]pcr
+.B /dev/lpt[123]psr
+.fi
+.SH DESCRIPTION
+The
+.I lpt
+driver provides an interface to the parallel
+interface normally used for printers.
+The specifiers
+.BR 1 ,
+.BR 2 ,
+and
+.BR 3
+correspond to
+the parallel interfaces at PC ports 0x3bc, 0x378, and 0x278
+respectively.
+.PP
+.B Lpt?data
+is write only.
+Writing to it sends data to the interface.
+This file is sufficient for communicating with most printers.
+.PP
+.BR Lpt?dlr ,
+.BR lpt?pcr ,
+and
+.B lpt?psr
+are used for fine control of the parallel port.
+Reading or writing these files corresponds to
+reading and writing the data latch register,
+printer control register, and printer status
+register.
+These are used by programs to drive special devices.
+.SH SOURCE
+.B /sys/src/9/pc/devlpt.c
diff --git a/static/plan9-4e/man3/mnt.3 b/static/plan9-4e/man3/mnt.3
new file mode 100644
index 00000000..c92c4370
--- /dev/null
+++ b/static/plan9-4e/man3/mnt.3
@@ -0,0 +1,72 @@
+.TH MNT 3 
+.SH NAME
+mnt \- attach to 9P servers
+.SH SYNOPSIS
+.nf
+.B #M
+.fi
+.SH DESCRIPTION
+The
+.I mount driver
+is used by the
+.B mount
+system call
+(but not
+.BR bind ;
+see
+.IR bind (2))
+to connect the name space of a process to
+the service provided by a 9P server over a communications channel.
+After the
+.BR mount ,
+system calls involving files in that portion of the name space will
+be converted by the mount driver into the appropriate
+9P messages to the server.
+.PP
+The
+.I mount
+system call issues
+.I session
+and
+.IR attach (5)
+messages to the server to identify and validate the user of the connection.
+Each distinct user of a connection must mount it separately;
+the mount driver multiplexes the access of the various users and their
+processes to the service.
+.PP
+File-oriented system calls are converted by the kernel into messages in the 9P protocol.
+Within the kernel, 9P is implemented by procedure calls to the
+various kernel device drivers.
+The mount driver translates these procedure calls into remote procedure calls
+to be transmitted as messages over the communication channel to the server.
+Each message is implemented by a write
+of the corresponding protocol message to the server channel
+followed by a read on the server channel to get the reply.
+Errors in the reply message are turned into system call error returns.
+.PP
+A
+.IR read (2)
+or
+.IR write
+system call on a file served by the mount driver
+may be translated
+into more than one
+message,
+since there is a maximum data size for a 9P message.
+The system call
+will return when the specified number of bytes have been transferred
+or a short reply is returned.
+.PP
+The string
+.L #M
+is an illegal file name,
+so this device can only be accessed directly by the kernel.
+.SH "SEE ALSO"
+.IR bind (2)
+.SH SOURCE
+.B /sys/src/9/port/devmnt.c
+.SH BUGS
+When mounting a service through the mount driver,
+that is, when the channel being multiplexed is itself
+a file being served by the mount driver,
+large messages may be broken in two.
diff --git a/static/plan9-4e/man3/mouse.3 b/static/plan9-4e/man3/mouse.3
new file mode 100644
index 00000000..f2bd33d8
--- /dev/null
+++ b/static/plan9-4e/man3/mouse.3
@@ -0,0 +1,213 @@
+.TH MOUSE 3
+.SH NAME
+mouse, cursor \- kernel mouse interface
+.SH SYNOPSIS
+.nf
+.B bind -a #m /dev
+
+.B /dev/mouse
+.B /dev/mousein
+.B /dev/mousectl
+.B /dev/cursor
+.fi
+.SH DESCRIPTION
+The 
+.I mouse
+device provides an interface to the mouse.
+There is also a cursor associated with the screen;
+it is always displayed at the current mouse position.
+.PP
+Reading the
+.B mouse
+file returns the mouse status: its position and button state.
+The read blocks until the state has changed since the last read.
+The read returns 49 bytes: the letter 
+.B m
+followed by four decimal strings, each 11 characters
+wide followed by a blank:
+.I x
+and
+.IR y ,
+coordinates of the mouse position in the screen image;
+.IR buttons ,
+a bitmask with the
+1, 2, and 4 bits set when the
+mouse's left, middle, and right buttons,
+respectively, are down;
+and
+.IR msec ,
+a time stamp, in units of milliseconds.
+.PP
+Writing the
+.B mouse
+file, in the same format,
+causes the mouse cursor to move to the position specified by the
+.I x
+and
+.I y
+coordinates of the message.
+The
+.I buttons
+and
+.I msec
+fields are ignored and may be omitted.
+.PP
+Writes to the 
+.B mousein
+file are processed as if they were generated by the
+mouse hardware itself,
+as extra mouse events to be processed and passed back via
+the
+.B mouse
+file.
+The
+.B mousein
+file, which is exclusive-use, is intended for controlling devices, such as USB mice,
+that are managed by user-level software.
+Each event should consist of
+the letter
+.B m
+followed by delta
+.IR x ,
+delta
+.IR y ,
+and
+.IR buttons
+as space-separated decimal numbers.
+.PP
+Writing to the
+.B mousectl
+file configures and controls the mouse.
+The messages are:
+.TF ps2intellimouse
+.TP
+.B serial\fI n\fR
+sets serial port
+.I n
+to be the mouse port.
+.TP
+.B ps2
+sets the PS2 port to be the mouse port.
+.TP
+.B intellimouse
+uses the wheel on a Microsoft Intellimouse
+as the middle button.
+.TP
+.B ps2intellimouse
+is equivalent to a write of
+.B ps2
+followed by a write of
+.BR intellimouse .
+.TP
+.B accelerated
+turns on mouse acceleration.
+.TP
+.B linear
+turns off mouse acceleration
+.TP
+.B res \fIn\fR
+sets mouse resolution to a setting between 0 and
+3 inclusive.
+.TP
+.B hwaccel \fIon/off\fR
+sets whether acceleration is done in hardware or
+software.
+By default, PS2 mice use hardware and serial mice use
+software.
+Some laptops (notably the IBM Thinkpad T23) don't
+implement hardware acceleration for external mice.
+.TP
+.B swap
+swaps the left and right buttons on the mouse.
+.TP
+.B buttonmap \fIxyz\fR
+numbers the left, middle, and right mouse buttons
+.IR x ,
+.IR y ,
+and
+.IR z ,
+respectively.
+If
+.I xyz
+is omitted, the default map, 123, is used.
+Thus in the default state writing
+.B "buttonmap 321
+swaps left and right buttons 
+and writing
+.B "buttonmap 123
+or just
+.B buttonmap
+restores their usual meaning.
+Note that
+.B buttonmap 
+messages are idempotent,
+unlike
+.BR swap .
+.TP
+.B reset
+clears the mouse
+to its default state.
+.PD
+.PP
+Not all mice interpret all messages; with some devices,
+some of the messages may be no-ops.
+.PP
+Cursors are described in 
+.IR graphics (2).
+When read or written from or to the
+.B cursor
+file, they are represented in a 72-byte binary format.
+The first and second four bytes are little endian
+32-bit numbers specifying the
+.I x
+and
+.I y 
+coordinates of the cursor 
+.IR offset ;
+the next 32 bytes are the
+.B clr
+bitmask,
+and the last 32 bytes the
+.B set
+bitmask.
+.PP
+Reading from the
+.B cursor
+file returns the current cursor information.
+Writing to the 
+.B cursor
+file sets the current cursor information.
+A write of fewer than 72 bytes sets the
+cursor to the default, an arrow.
+.PP
+The
+.B mouse
+and
+.B cursor
+files are multiplexed by
+.IR rio (1)
+to give the illusion of a private mouse to each of its clients.
+The semantics are otherwise the same except that notification
+of a window resize is passed to the application using a
+.B mouse
+message beginning with
+.B r
+rather than
+.BR m ;
+see
+.IR rio (4)
+for details.
+.PP
+To cope with pointing devices with only two buttons, when the
+shift key is pressed, the right mouse button generates middle-button events.
+.SH SOURCE
+.B /sys/src/9/port/devmouse.c
+.SH "SEE ALSO
+.IR rio (4)
+.SH BUGS
+The cursor format is big endian while the
+rest of the graphics interface is little endian.
+.PP
+The
+.B mousein
+file is disabled.
diff --git a/static/plan9-4e/man3/pipe.3 b/static/plan9-4e/man3/pipe.3
new file mode 100644
index 00000000..fb93fa4d
--- /dev/null
+++ b/static/plan9-4e/man3/pipe.3
@@ -0,0 +1,59 @@
+.TH PIPE 3 
+.SH NAME
+pipe \- two-way interprocess communication
+.SH SYNOPSIS
+.B bind #|
+.I dir
+.nf
+
+.IB dir /data
+.IB dir /ctl
+.IB dir /data1
+.IB dir /ctl1
+.fi
+.SH DESCRIPTION
+.PP
+An
+.IR attach (5)
+of this device allocates two new cross-connected I/O streams.
+.B X/data
+and
+.B x/ctl
+are the data and control channels of one stream and
+.B x/data1
+and
+.B x/ctl1
+are the data and control channels of the other stream.
+.PP
+Data written to one channel becomes available for reading at
+the other.
+Write boundaries are preserved: each read terminates
+when the read buffer is full or after reading the last byte
+of a write, whichever comes first.
+.PP
+Writes are atomic up to a certain size, typically 32768 bytes,
+that is, each write will be delivered in a single read by the
+recipient, provided the receiving buffer is large enough.
+.PP
+If there are multiple writers, each
+.I write
+is guaranteed to be available in a contiguous piece at the other
+end of the pipe.
+If there are multiple readers, each read will return data from only
+one write.
+.PP
+The
+.IR pipe (2)
+system call performs an
+.I attach
+of this device and returns file descriptors to the new pipe's
+.B data
+and
+.B data1
+files.
+The files are open with mode
+.BR ORDWR .
+.SH "SEE ALSO"
+.IR pipe (2)
+.SH SOURCE
+.B /sys/src/9/port/devpipe.c
diff --git a/static/plan9-4e/man3/pnp.3 b/static/plan9-4e/man3/pnp.3
new file mode 100644
index 00000000..4ad193a5
--- /dev/null
+++ b/static/plan9-4e/man3/pnp.3
@@ -0,0 +1,146 @@
+.TH PNP 3 
+.SH NAME
+pnp \- Plug 'n' Play ISA and PCI Interfaces
+.SH SYNOPSIS
+.nf
+.B bind -a '#$' /dev
+
+.BI /dev/pci/ bus\fL.\fPdev\fL.\fPfn ctl
+.BI /dev/pci/ bus\fL.\fPdev\fL.\fPfn raw
+
+.BI /dev/pnp/ctl
+.BI /dev/pnp/csn n ctl
+.BI /dev/pnp/csn n raw
+\&...
+
+.fi
+.SH DESCRIPTION
+.PP
+This device provides a limited interface to the PCI bus and
+Plug 'n' Play ISA devices.
+.SS PCI Interface
+.PP
+PCI devices are addressed logically by a bus number,
+a device number on that bus, and a function number
+within the device.
+The set of all such device functions may be enumerated
+by traversing the
+.B /dev/pci
+directory; the driver serves two files for each function.
+These are a control file
+.RL ( /dev/pci/\fIbus\fP.\fIdev\fP.\fIfn\fPctl )
+which may be read for a textual summary of the device function,
+and a `raw' file
+.RL ( /dev/pci/\fIbus\fP.\fIdev\fP.\fIfn\fPraw )
+which may be read to obtain the raw contents of PCI configuration space.
+.PP
+The first field of a PCI control file contains the class, sub-class and
+programming interface values for the device function, expressed
+as 2-digit hexadecimal values, and separated by periods.
+The second field yields the vendor ID and device ID, each as 4-digit
+hex numbers, separated by a slash.
+The third field is the associated interrupt line in decimal.
+The remainder of the line enumerates any valid base address
+registers for the function, using two fields for each.
+In the first field, the index of the register is followed by
+a colon, and then the value of the register itself.
+The following field gives the associated size of the memory
+(or I/O space) that is mapped by the register.
+.SS Plug 'n' Play
+.PP
+Plug 'n' Play ISA devices are discovered by sending a fixed `unlock' sequence
+over an I/O port, and then reading back data from another port.
+An arbitration algorithm is used to separate out the individual
+cards and enumerate them in turn.
+Each card is assigned a unique number, called a CSN, in the range 1-255 as a
+result of enumeration.
+Cards also have a fixed 64 bit identification number, set by the
+manufacturer, which is used by the arbitration algorithm to
+resolve conflicts.
+The first 32 bits describe the type of the card, and the second
+32 bits form a serial number for the particular instance of that card type.
+When formatted textually, it appears as 3 upper-case letters
+(typically representing the manufacturer),
+followed by 4 hex digits, then a period, then 8 hex digits.
+The substring before the period is the card type, and the substring
+after the period is the serial number.
+.PP
+The enumeration algorithm needs to be enabled by specifying the
+port number to write the unlock sequence out on.
+This can be configured to take place at boot time by adding a line
+like the following to
+.IR plan9.ini :
+.IP
+.EX
+pnp0=port=0x203
+.EE
+.PP
+Here
+.B port
+should be chosen to not conflict with any existing devices.
+It must be in the range
+.BR 0x203-0x3ff .
+Alternatively, one can use the following command:
+.IP
+.EX
+echo port 0x203 >/dev/pnp/ctl
+.EE
+.PP
+Note that a side-effect of PnP enumeration is to reset the configuration
+state of all such cards; any settings made by a Plug and Play BIOS will be lost.
+Reading the file
+.B /dev/pnp/ctl
+returns one of the strings
+.B "enabled\fI port\fP"
+or
+.BR "disabled" .
+.PP
+For each enumerated card, two files are served in
+.BR /dev/pnp .
+A control file
+.RL ( /dev/pnp/csn\fIn\fPctl )
+may be read to determine the ID of the card, and a raw file
+.RL ( /dev/pnp/csn\fIn\fPraw )
+may be read to obtain the configuration data associated with the card.
+It is intended that the control file should take commands which set the
+various configurable resources of the card, but this has not been
+implemented yet.
+.PP
+A mechanism is provided for configuring cards via
+.IR plan9.ini (8).
+A line of the form
+.BI pnp n = "idstring ..."
+will cause the driver to look for the card named by
+.I idstring
+and, if found, assign it the CSN
+.IR n .
+The intention is that
+any additional text after the idstring is interpreted as if it
+was written to the card's
+.B ctl
+file, but this is not yet implemented.
+.SH EXAMPLES
+.PP
+To list all PCI functions:
+.IP
+.EX
+cat /dev/pci/*ctl
+.EE
+.PP
+To find just the PCI video card (class 3):
+.IP
+.EX
+grep '^03' /dev/pci/*ctl
+.EE
+.SH SOURCE
+.B /sys/src/9/port/devpnp.c
+.SH BUGS
+There is currently no way to write to PCI configuration space,
+or to perform reads of less than 32 bits.
+Access to the I/O and memory regions of a PCI device is not provided.
+.PP
+The ability to set a Plug 'n' Play card's configurable settings has not been
+implemented.
+.PP
+There should be a user program for identifying and configuring
+Plug 'n' Play cards.
diff --git a/static/plan9-4e/man3/proc.3 b/static/plan9-4e/man3/proc.3
new file mode 100644
index 00000000..45d5d40e
--- /dev/null
+++ b/static/plan9-4e/man3/proc.3
@@ -0,0 +1,328 @@
+.TH PROC 3 
+.SH NAME
+proc \- running processes
+.SH SYNOPSIS
+.nf
+.B bind #p /proc
+
+.BI /proc/ n /args
+.BI /proc/ n /ctl
+.BI /proc/ n /fd
+.BI /proc/ n /fpregs
+.BI /proc/ n /kregs
+.BI /proc/ n /mem
+.BI /proc/ n /note
+.BI /proc/ n /noteid
+.BI /proc/ n /notepg
+.BI /proc/ n /ns
+.BI /proc/ n /proc
+.BI /proc/ n /profile
+.BI /proc/ n /regs
+.BI /proc/ n /segment
+.BI /proc/ n /status
+.BI /proc/ n /text
+.BI /proc/ n /wait
+\&...
+.fi
+.SH DESCRIPTION
+The
+.I proc
+device serves a two-level directory structure.
+The first level contains numbered directories
+corresponding to pids of live processes;
+each such directory contains a set of files
+representing the corresponding process.
+.PP
+The
+.B mem
+file contains the current memory image of the process.
+A read or write at offset
+.IR o ,
+which must be a valid virtual address,
+accesses bytes from address
+.IR o
+up to the end of the memory segment containing
+.IR o .
+Kernel virtual memory, including the kernel stack for the process and
+saved user registers (whose addresses are machine-dependent),
+can be accessed through
+.BR mem .
+Writes are permitted only while the process is in the
+.B Stopped
+state and only to user addresses or registers.
+.PP
+The read-only
+.B proc
+file contains the kernel per-process
+structure.
+Its main use is to recover the kernel stack and program counter
+for kernel debugging.
+.PP
+The files
+.BR regs ,
+.BR fpregs ,
+and
+.BR kregs
+hold representations of the user-level registers, floating-point registers,
+and kernel registers in machine-dependent form.
+The
+.B kregs
+file is read-only.
+.PP
+The read-only
+.B fd
+file lists the open file descriptors of the process.
+The first line of the file is its current directory; subsequent lines list, one per line,
+the open files, giving the decimal file descriptor number; whether the file is open for read
+.RB ( r ),
+write,
+.RB ( w ),
+or both
+.RB ( rw );
+the type, device number, and qid of the file; its I/O unit (the amount of data
+that may be transferred on the file as a contiguous piece; see
+.IR iounit (2)),
+its I/O offset; and its name at the time it was opened.
+.PP
+The read-only
+.B ns
+file contains a textual representation of the process's file name space, in the format of
+.IR namespace (6)
+accepted by
+.B newns
+(see
+.IR auth (2)).
+The last line of the file identifies the current working directory of the process, in the form of a
+.B cd
+command
+(see
+.IR rc (1)).
+The information in this file is based on the names files had when the name space was assembled,
+so the names it contains may be inaccessible if the files have been subsequently renamed or rearranged.
+.PP
+The read-only
+.B segment
+file contains a textual display of the memory segments
+attached to the process.  Each line has multiple fields:
+the type of segment (\c
+.BR Stack ,
+.BR Text ,
+.BR Data ,
+.BR Bss ,
+etc.); one-letter flags such as
+.B R
+for read-only, if any;
+starting virtual address, in hexadecimal;
+ending virtual address, and reference count.
+.PP
+The read-only
+.B status
+file contains a string with twelve fields, each followed by a space.
+The fields are:
+.IP \-
+the process name and user name, each 27 characters left justified
+.IP \-
+the process state, 11 characters left justified (see
+.IR ps (1))
+.IP \-
+the six 11-character numbers also held in the process's
+.B #c/cputime
+file
+.IP \-
+the amount of memory used by the process, except its stack,
+in units of 1024 bytes
+.IP \-
+the base and current scheduling priority, each 11 character numbers
+.PP
+The read-only
+.B args
+file contains the arguments of the program when it was created by
+.IR exec (2).
+If the program was not created by
+.BR exec ,
+such as by
+.IR fork (2),
+its
+.B args
+file will be empty.
+The format of the file is a list of quoted strings suitable for
+.BR tokenize ;
+see
+.IR getfields (2).
+.PP
+The
+.B text
+file is a pseudonym for the file
+from which the process was executed;
+its main use is to recover the symbol table of the process.
+.PP
+The
+.B wait
+file may be read to recover
+records from the exiting children of the process in the format of
+.B await
+(see
+.IR wait (2)).
+If the process has no extant children, living or exited,
+a read of
+.B wait
+will block.
+It is an error for a process to attempt to read its own
+.B wait
+file when it has no children.
+When a process's
+.B wait
+file is being read,
+the process will draw an error
+if it attempts an
+.B await
+system call; similarly, if a process is in an
+.B await
+system call, its
+.B wait
+file cannot be read by any process.
+.PP
+Textual messages written to the
+.B ctl
+file control the execution of the process.
+Some require that the process is in a particular state
+and return an error if it is not.
+.TP 10n
+.B stop
+Suspend execution of the process, putting it in the
+.B Stopped
+state.
+.TP 10n
+.B start
+Resume execution of a
+.B Stopped
+process.
+.TP 10n
+.B waitstop
+Do not affect the process directly but, like all other messages ending with
+.BR stop ,
+block the process writing the
+.B ctl
+file until the target process is in the
+.B Stopped
+state or exits.
+Also like other
+.B stop
+control messages,
+if the target process would receive a note while the message is pending,
+it is instead stopped and the debugging process is resumed.
+.TP 10n
+.B startstop
+Allow a
+.B Stopped
+process to resume, and then do a
+.B waitstop
+action.
+.TP 10n
+.B hang
+Set a bit in the process so that,
+when it completes an
+.IR exec (2)
+system call, it will enter the
+.B Stopped
+state before returning to user mode.
+This bit is inherited across
+.IR fork (2)
+and
+.IR exec (2).
+.TP 10n
+.B "close\ \fIn
+Close file descriptor
+.I n
+in the process.
+.TP 10n
+.B closefiles
+Close all open file descriptors in the process.
+.TP 10n
+.B nohang
+Clear the hang bit.
+.TP 10n
+.B kill
+Kill the process the next time it crosses the user/kernel boundary.
+.TP 10n
+.B private
+Make it impossible to read the process's user memory.
+This property is inherited on fork, cleared on
+.IR exec (2),
+and is not otherwise resettable.
+.TP 10n
+.B "pri\ \fIn
+Set the base priority for the process to the integer
+.IR n .
+.TP 10n
+.B "wire\ \fIn
+Wire the process to processor
+.IR n .
+.PD
+.PP
+The priority is interpreted by Plan 9's multilevel process scheduler.
+Priorities run from 0 to 19, with higher
+numbers representing higher priorities.
+A process has a base priority and
+a running priority which is less than or equal to the base priority.
+As a process uses up more of its allocated time, its priority is lowered.
+Unless
+explicitly set, user processes have base priority 10, kernel processes
+13.
+Children inherit the parent's base priority.
+.PP
+The read-only
+.B profile
+file contains the instruction frequency count information used for multiprocess profiling; see
+.B tprof
+in
+.IR prof (1).
+The information is gleaned by sampling the program's user-level program counter
+at interrupt time.
+.PP
+Strings written to the
+.B note
+file will be posted as a note to the process
+(see
+.IR notify (2)).
+The note should be less than
+.B ERRLEN-1
+characters long;
+the last character is reserved for a terminating NUL character.
+A read of at least
+.B ERRLEN
+characters will retrieve the oldest note posted to the
+process and prevent its delivery to the process.
+The
+.B notepg
+file is similar, but the note will be delivered to all the
+processes in the target process's
+.I note group
+(see
+.IR fork (2)).
+However, if the process doing the write is in the group,
+it will not receive the note.
+The
+.B notepg
+file is write-only.
+.PP
+The textual
+.B noteid
+file may be read to recover an integer identifying the note group of the process
+(see
+.B RFNOTEG
+in
+.IR fork (2)).
+The file may be written to cause the process to change to another note group,
+provided the group exists and is owned by the same user.
+.SH FILES
+.nf
+.B /sys/src/9/*/mem.h
+.B /sys/src/9/*/dat.h
+.fi
+.SH SEE ALSO
+.IR debugger (2),
+.IR mach (2),
+.IR cons (3)
+.SH SOURCE
+.B /sys/src/9/port/devproc.c
diff --git a/static/plan9-4e/man3/realtime.3 b/static/plan9-4e/man3/realtime.3
new file mode 100644
index 00000000..b9bcc7f7
--- /dev/null
+++ b/static/plan9-4e/man3/realtime.3
@@ -0,0 +1,316 @@
+.TH REALTIME 3 
+.EQ
+delim $$
+.EN
+.SH NAME
+realtime \- real time scheduling
+.SH SYNOPSIS
+.EX
+.ta 4n +4n +4n +4n +4n +4n +4n
+.B bind -a #R /dev
+.ift .sp 0.5
+.ifn .sp
+/dev/realtime/clone
+/dev/realtime/debug
+/dev/realtime/log
+/dev/realtime/nblog
+/dev/realtime/resources
+/dev/realtime/task/0
+/dev/realtime/task/1
+/dev/realtime/task/...
+/dev/realtime/time
+.sp
+#include /sys/src/port/9/devrealtime.h
+.ift .sp 0.5
+.ifn .sp
+enum SEvent {
+	SAdmit,		/* new proc arrives*/
+	SRelease,	/* released, but not yet scheduled */
+	SRun,		/* one of this task's procs started running */
+	SPreempt,	/* the running task was preempted */
+	SBlock,		/* the last of the runnable procs in a task blocked */
+	SResume,	/* task was scheduled after blocking */
+	SDeadline,	/* proc's deadline (reported ahead of time) */
+	SYield,		/* proc reached voluntary early deadline */
+	SSlice,		/* slice exhausted */
+	SExpel,		/* proc was expelled */
+};
+typedef enum SEvent SEvent;
+typedef vlong Time;
+typedef struct Schedevent Schedevent;
+.ift .sp 0.5
+.ifn .sp
+struct Schedevent {
+	ushort	tid;		/* Task ID */
+	SEvent	etype;	/* Event type */
+	Time	ts;		/* Event time */
+};
+.EE
+.SH DESCRIPTION
+The Plan 9 real-time scheduler allows mixing real-time processes and best-effort
+processes on a single system.  The scheduler is intended for real-time loads well
+under 100% CPU utilization with minimum periods in the order of a hundred thousand
+instruction times.  The precision of the scheduler depends on the precision of the
+machine's programmable real-time clock.
+.PP
+The unit of real-time scheduling is a
+.BR task .
+A task can contain zero or more processes.  The processes in a task share a common
+period, deadline and CPU allocation.  Tasks allow cooperating processes to collaborate
+to achieve a common deadline, for instance, processes receiving, decompressing and
+displaying video in a pipeline can share a single task.
+.PP
+Tasks are scheduled using Earliest-Deadline First (EDF).  Each task has three primary
+scheduling parameters, a period $T$, a deadline $D$ and a cost $C$, expressed in
+nanoseconds (but converted to a machine- and architecture-dependent unit called
+.IR ticks ).
+Every $T$ nanoseconds, the task is
+.I released
+— i.e., it becomes schedulable — and it received a
+.I slice
+of $C$ nsec.
+When the task is released, its
+.I "release time"
+$r$ is set to the current time.
+The task's
+.I "absolute deadline"
+$d$ is set to $r + D$.
+(Note the use of capital letters to indicate intervals and lower-case letters to indicate
+`points in time'.)
+Between release and deadline the task must
+be scheduled often enough to be able to consume its slice of $C$ nsec of CPU time.
+So, to be schedulable, $C <= D <= T$ must hold.
+If $D < T$, tasks are not schedulable (runnable) between their deadline and the next
+release.
+Tasks are
+.I released
+from the moment of release until their deadline or their slice runs out, whichever
+happens first.  Additionally, tasks can voluntarily declare the slice for the current period
+empty, allowing other real-time tasks or best-effort tasks the CPU time remaining in
+their slice.
+.PP
+Before they are released for the first time, tasks have to be
+.IR admitted
+into the system.  Before admission, a test is conducted to determine whether the task,
+plus the already admitted tasks can all meet their deadlines, given their scheduling
+parameters.  When a task changes its scheduling parameters, it is temporarily
+.I expelled
+and will be readmitted if the new scheduling parameters allow all tasks to continue
+to meet their deadlines.
+.PP
+The EDF scheduler schedules the released task with the earliest deadline.  When a task
+is released, therefore, it can preempt a task that has a later deadline, but was released earlier.
+Real-time tasks sharing resources, however, may need to be prevented from preempting
+each other.  They can do this by declaring a shared resource.  The scheduler will not
+preempt one task with another that shares a common resource.  To do this, the scheduler only
+needs to know the names of the sharable resources used by each of the tasks.
+.PP
+During the admission test, information about shared resources is used to calculate
+a secondary deadline for each task, called the
+.IR "inherited deadline" ,
+$Δ$, which is the minimum of the deadlines $D$ of each of the tasks that shares a
+resource with the current task.
+The scheduler allows a released task $T$ to preempt running task $T'$ iff
+$d < d' ^ D < Δ'$; the first half of the condition says that the released task's deadline
+must be earlier, the second implies that the released task may not share resources with
+the running one.
+The admission test takes these limitations into account.  Note that, in practice, tasks
+rarely share resources.
+.PP
+Normally, tasks can block (when all their processes are blocked on system calls) during
+their release.
+The time spent blocking is not accounted against the current slice, but, since the scheduler
+has no control over the time spent blocking, there are no guarantees that the deadline
+will be made if a task spends any time blocked.
+Whether or not tasks actually block, they will normally complete the work to be done
+in a period (slightly) before the slice runs out — and before the deadline.  To tell the
+scheduler that they no longer require the CPU until the next release, tasks can
+.I yield
+(see below).
+.PP
+Tasks can also run in another mode where blocking automatically implies immediate
+yielding.  This mode truly guarantees that deadlines will be made, but programmers
+must know more about the (blocking) nature of the system calls used in order to use
+this mode.
+.sp
+.LP
+The real-time scheduler is controlled through a file system (naturally), normally
+bound to
+.BR /dev .
+Opening
+.B /dev/realtime/clone
+for writing (and reading, if desired), causes a new task to be created in the
+non-admitted (expelled) state.  The new task will be represented by a file in
+the
+.B /dev/realtime/task
+directory whose name is the task's number.
+The file descriptor resulting from opening
+.B /dev/realtime/clone
+provides the equivalent functionality as that resulting from opening
+.BI /dev/realtime/task/ n
+except for the initial creation of a new task when opening the
+.B clone
+file.  The task file may also be opened read-only.
+.PP
+The tasks parameters are set or modified by writing one of these files and they
+can be examined by reading it.
+A parameter is presented in the form
+\f2name\fP=\f2value\fP, \f2name\fP+=\f2value\fP, or \f2name\fP-=\f2value\fP.
+A command is presented in the form
+.IR commandname .
+Parameters and commands are separated by white space; quoting conventions apply
+(see
+.IR quote (2)).
+The settable parameters are
+.TP
+.B T
+Sets the period.  The value must be given as a number with or without decimal point
+and directly followed (no white space) by one of
+.I s
+for seconds,
+.I ms
+for milliseconds,
+.I µs
+or
+.I us
+for microseconds,
+.I ns
+or
+nothing
+for nanoseconds.  The
+.B +=
+operator adds to the period already set, the
+.B -=
+operator subtracts from it.
+.TP
+.B D
+Sets the deadline.  Value syntax and operators as above.
+.TP
+.B C
+Sets the cost.  Value syntax and operators as above.
+.TP
+.B resources
+Sets the list of resources; resource names are separated by white space and
+quoting must be used in this case.  A resource name is an arbitrary string.  The
+.B +=
+operator adds to the list of resources
+.B -=
+operator takes away from it.
+.TP
+.B procs
+Sets, adds to, or subtracts from the process membership of a task.  Processes
+are identified by their
+.I pid
+or the special value
+.B self
+identifying the process writing the
+.I clone
+or
+.I task
+file.
+.TP
+.B yieldonblock
+When the (integer) value is non-zero, the task is placed in
+.I yield-on-block
+mode: when all processes in the task are blocked on system calls, the task automatically
+declares the current deadline reached and will be released again in the next period.
+When the value is zero, the task can block without forfeiting the current release.
+However, when the task blocks long, the deadline may be missed.  The default value is zero.
+.LP
+The commands accepted are
+.TP
+.B verbose
+This is for debugging and causes the progression of the admission test to be displayed.
+.TP
+.B admit
+This initiates an admission test.  If the test fails, the write containing the
+.B admit
+command will fail.  If the test succeeds the task is admitted and, if it contains
+runnable processes, it will be released (almost) immediately.
+.TP
+.B expel
+Expel the task.
+.TP
+.B remove
+Remove the task, the file descriptor will become invalid.
+.TP
+.B yield
+Gives up the processor until the next release.
+.LP
+.sp
+.B /dev/realtime/debug
+prints debugging information about the task queues maintained by the scheduler.
+This file will go away.
+.PP
+.B /dev/realtime/log
+and
+.B /dev/realtime/nblog
+are files used by real-time monitoring processes such as
+.B rtstats
+(see
+.IR rtstats (1)).
+Reading them produces a stream of
+.B Schedevent
+structures in the machine representation.  These events are
+nearly ordered by Time (nanoseconds since boot); some events can
+be reported earlier or later than they occur.
+.I Tid
+corresponds to the file name in the directory
+.BR /dev/realtime/task ,
+.I etype
+is one of the events of
+.I SEvent
+as explained in
+.BR /sys/src/9/port/devrealtime.h ,
+and
+.I ts
+is the time at which the event occurred (or will occur).
+.B Nblog
+is a non-blocking version that returns zero bytes each time there is
+nothing left to read.
+.PP
+.B /dev/realtime/resources
+is a read-only file listing the resources declared by the current set of tasks.
+.PP
+.B /dev/realtime/time
+returns the number of nanoseconds since boot, the number of ticks since boot and
+.IR fasthz ,
+the number of clock ticks per second, a billion times the ratio between the other two numbers.
+Each number is returned as a binary
+.I vlong
+in architecture-dependent representation.
+.SH EXAMPLE
+.EX
+.ta 4n +4n +4n +4n +4n +4n +4n
+char *clonedev = "#R/realtime/clone";
+
+void
+processvideo(){
+	int fd;
+
+	if ((fd = open(clonedev, ORDWR)) < 0) 
+		sysfatal("%s: %r", clonedev);
+	if (fprint(fd, "T=33ms D=20ms C=8ms procs=self admit") < 0)
+		sysfatal("%s: admit: %r", clonedev);
+	for (;;){
+		processframe();
+		if (fprint(fd, "yield") < 0)
+			sysfatal("%s: yield: %r", clonedev);
+	}
+	if (fprint(fd, "remove") < 0)
+		sysfatal("%s: remove: %r", clonedev);
+	close(fd);
+}
+.EE
+.SH "SEE ALSO
+.IR rtstats (1)
+.SH FILES
+.B /usr/sape/src/realtime/edfproc.c
+as an example of using the scheduler for a trivial test run.
+.SH SOURCE
+.B /sys/src/9/port/devrealtime.c
+.br
+.B /sys/src/9/port/edf.c
+.SH BUGS
+The admission test does not take multiprocessors into account.  The total
+real-time load cannot exceed a single-\s-2CPU\s0 load.
diff --git a/static/plan9-4e/man3/root.3 b/static/plan9-4e/man3/root.3
new file mode 100644
index 00000000..ff12df61
--- /dev/null
+++ b/static/plan9-4e/man3/root.3
@@ -0,0 +1,39 @@
+.TH ROOT 3 
+.SH NAME
+root \- the root file system
+.SH SYNOPSIS
+.nf
+.B /
+.B /boot
+.B /dev
+.B /env
+.B /net
+.B /net.alt
+.B /proc
+.B /root
+.B /srv
+.fi
+.SH DESCRIPTION
+The syntax
+.L #/
+is illegal, so this device can only be accessed directly by the kernel.
+.PP
+This device is set up by the kernel to be the root of
+the name space.
+The names in the one-level tree are mostly just place-holders,
+to allow a place to
+.IR bind (2)
+to.
+The exception is
+.BR /boot ,
+which provides executable code when read.
+The kernel does an
+.IR exec (2)
+of
+.B /boot
+when initializing.
+Some kernels are built with other services, such as
+.IR kfs (4) ,
+in the root directory.
+.SH SOURCE
+.B /sys/src/9/port/devroot.c
diff --git a/static/plan9-4e/man3/rtc.3 b/static/plan9-4e/man3/rtc.3
new file mode 100644
index 00000000..da30231f
--- /dev/null
+++ b/static/plan9-4e/man3/rtc.3
@@ -0,0 +1,40 @@
+.TH RTC 3
+.SH NAME
+rtc \- real-time clock and non-volatile RAM
+.SH SYNOPSIS
+.B bind #r /dev
+.PP
+.B /dev/rtc
+.br
+.B /dev/nvram
+.SH DESCRIPTION
+The
+.I rtc
+device supports devices
+with real-time clocks and non-volatile RAM.
+.PP
+The
+.B rtc
+file behaves just like
+.BR /dev/time
+(see
+.IR cons (3)).
+The real-time clock is maintained on-board;
+.B /dev/time
+is set from the file server.  Neither is necessarily more accurate.
+.PP
+The
+.B nvram
+file provides (if permission allows)
+access to the local non-volatile RAM.
+For example,
+.IR boot (8)
+reads the machine's key
+from there
+(see
+.IR auth (8)).
+.SH SEE ALSO
+.IR auth (8),
+.IR boot (8)
+.SH SOURCE
+.B /sys/src/9/*/devrtc.c
diff --git a/static/plan9-4e/man3/sd.3 b/static/plan9-4e/man3/sd.3
new file mode 100644
index 00000000..99b851cd
--- /dev/null
+++ b/static/plan9-4e/man3/sd.3
@@ -0,0 +1,209 @@
+.TH SD 3 
+.SH NAME
+sd \- storage device interface
+.SH SYNOPSIS
+.nf
+.B bind #S /dev
+
+.BI /dev/sd Cu /ctl
+.BI /dev/sd Cu /raw
+.BI /dev/sd Cu /data
+\&...
+.fi
+.SH DESCRIPTION
+.PP
+The storage device interface serves a two-level directory
+giving access to multiple storage units,
+typically ATA(PI) or SCSI discs.
+Each unit
+is accessed via files in the directory named by the controller
+to which it is attached,
+.IR C  ,
+and by its unit number
+.IR u .
+The controller naming convention for ATA(PI) units starts
+with the first controller being named
+.LR C ,
+the second
+.LR D ,
+etc. up to a maximum of 4 controllers
+.RB ([ C-F ]);
+legacy controllers are always 'C' and 'D'.
+There can be a maximum of 2 units per ATA(PI) controller
+.RB ([ 01 ]).
+The controller naming convention for SCSI units starts with
+the first controller being named
+.LR 0 ,
+the second
+.LR 1 ,
+etc. up to a maximum of 16 controllers
+.RB ([ 0-9a-f ]).
+There can be a maximum of 16 units per SCSI controller
+.RB ([ 0-9a-f ]).
+.PP
+Units are not accessed before the first attach.
+Units may be individually attached using the attach specifier,
+for example
+.IP
+.EX
+bind -a '#SsdD0' /dev
+.EE
+.PP
+An attach without a specifier will cause the driver to scan for all possible
+units before processing the rest of the name.
+.PP
+The subdirectory for each unit contains two files,
+.I ctl
+and
+.IR raw .
+In addition,
+if the unit is a direct-access disc of some type
+it may be split into partitions and
+the subdirectory may contain a file per partition.
+By default,
+the partition
+.I data
+will exist for such media.
+.PP
+Partitions are added and deleted by writing to the
+.I ctl
+file
+.IP
+.EX
+part \f2name start-sector end-sector\fP
+delpart \f2name\fP
+.EE
+.PP
+The default
+.I data
+partition may be deleted.
+A partition cannot be deleted if a process has it open.
+If a change of removable media is detected,
+the new media cannot be opened until all open partitions
+on the old media are closed.
+.PP
+Partitions are usually created using
+.I fdisk
+and
+.IR prep (8);
+the convention is to name non-Plan 9 partitions after their corresponding operating systems
+(e.g.,
+.BR /dev/sdC0/dos )
+and Plan 9 partitions according to their function
+(e.g.,
+.BR /dev/sdC0/swap ).
+The example in
+.IR prep (8)
+shows how this is done.
+.PP
+Reading the
+.I ctl
+file returns at least one line of textual information about
+the unit.
+The first line will always be prefixed by
+.B inquiry
+and will give a manufacturer and model number if possible.
+A line prefixed by
+.B config
+will be returned for appropriate media,
+e.g. for ATA(PI) units the remainder of the line contains
+configuration information from the device's
+.I identify
+command (config and capabilities)
+and also the available I/O transfer options;
+this is a diagnostic aid.
+A line prefixed by
+.B geometry
+will be returned for appropriate media;
+at least two numbers will follow,
+the first being the number of sectors contained in the unit
+and the second the sector size in bytes.
+Any remaining information on the
+.B geometry
+line is unit-dependent,
+for instance, head,
+cylinder and sector counts for ATA discs.
+If any partitions are defined for the media,
+their name, start-sector and end-sector will be returned,
+prefixed by
+.BR part .
+.IP
+.EX
+% cat /dev/sdD0/ctl
+inquiry KENWOOD CD-ROM UCR-421  208E10/20/99  7.39  2 M0
+config 85C0 capabilities 0F00 dma 00550004 dmactl 00000000
+geometry 242725 2352
+part data 0 242725
+% 
+.EE
+.PP
+The use of DMA and multi-sector read/write commands may be
+enabled and disabled on ATA(PI) units by writing to the
+.B ctl
+file
+.B dma
+and
+.B rwm
+respectively followed by
+.B on
+or
+.BR off .
+For example, to enable DMA on a unit that supports it:
+.IP
+.EX
+% echo 'dma on'>/dev/sd00/ctl
+.EE
+.PP
+If supported by the unit,
+the standby timer may be enabled:
+.IP
+.EX
+% echo 'standby \f2T\fP'>/dev/sdC0/ctl
+.EE
+.PP
+where
+.I T
+is the standby timer period in seconds.
+.I T
+must be between 30 and 1200,
+or can be 0 to disable the timer.
+.PP
+The
+.B raw
+file is used to execute an arbitrary command on the unit at
+a low level.
+This is used by programs such as
+.IR scuzz (8)
+to manipulate devices that do not fit the simple storage model
+or for maintenance purposes.
+The following steps may be used to execute a command
+.IP
+\- Write the command to the
+.I raw
+file;
+.IP
+\- Read or write data associated with the command, according to the direction of the transfer.
+.IP
+\- Read the
+.I raw
+file to retrieve the status of the command,
+returned as a text integer.
+.SH SOURCE
+.B /sys/src/9/port/devsd.c
+.br
+.B /sys/src/9/*/sd*.[hc]
+.SH SEE ALSO
+.IR scuzz (8)
+.SH BUGS
+.PP
+Still in development.
+.PP
+No LUNs.
+.PP
+The 4 controller limit for ATA(PI) is not enforced.
+.PP
+No account is taken of some buggy ATA PCI controllers
+such as the CMD640.
+.PP
+ATA(PI) units come up with DMA and multi-sector read/write
+capability disabled.
diff --git a/static/plan9-4e/man3/segment.3 b/static/plan9-4e/man3/segment.3
new file mode 100644
index 00000000..1a8e5e71
--- /dev/null
+++ b/static/plan9-4e/man3/segment.3
@@ -0,0 +1,117 @@
+.TH SEGMENT 3 
+.SH NAME
+segment \- long lived memory segments
+.SH SYNOPSIS
+.nf
+.B bind '#g' /mnt/segment
+
+.BI #g/ seg1
+.BI #g/ seg1 /ctl
+.BI #g/ seg1 /data
+.BI #g/ seg2
+.BI #g/ seg2 /ctl
+.BI #g/ seg2 /data
+ ...
+.fi
+.SH DESCRIPTION
+.PP
+The
+.I segment
+device provides a 2-level file system representing
+long-lived sharable segments that processes may
+.IR segattach (2).
+The name of the directory is the
+.I class
+argument to
+.IR segattach .
+.PP
+New segments are created under the top level
+using
+.B create
+(see
+.IR open (2)).
+The
+.B DMDIR
+bit must be set in the permissions.
+.IR Remove (2)'ing
+the directory makes the segment no longer
+available for
+.IR segattach .
+However, the segment will continue to exist until all
+processes using it either exit or
+.I segdetach
+it.
+.PP
+Within each segment directory are two files,
+.B data
+and
+.BR ctl .
+Reading and writing
+.B data
+affects the contents of the segment.
+Reading and writing 
+.B ctl
+retrieves and sets the segment's properties.
+.PP
+There is only one control message, which sets the segment's
+virtual address and length in bytes:
+.EX
+	va \fIaddress length\fP
+.EE
+.I Address
+is automatically rounded down to a page boundary and
+.I length
+is rounded up to end the segment at a page boundary.
+The segment will reside at the same virtual address in
+all processes sharing it.
+When the segment
+is attached using
+.IR segattach,
+the address and length arguments are ignored in the call;
+they are defined only by the
+.B va
+control message.
+Once the address and length are set, they cannot be reset.
+.PP
+Reading the control file
+returns a message of the same format with the segment's actual
+start address and length.
+.PP
+Opening
+.B data
+or reading
+.B ctl
+before setting the virtual address yields the error
+``segment not yet allocated''.
+.PP
+The permissions check when
+.IR segattach ing
+is equivalent to the one performed when opening
+.B data
+with mode ORDWR.
+.SH EXAMPLE
+.PP
+Create a one megabyte segment at address 0x10000000:
+.EX
+	% bind '#g' /mnt/segment
+	% mkdir /mnt/segment/example
+	% echo 'va 0x10000000 0x100000' > /mnt/segment/example/ctl
+.EE
+.PP
+Put the string ``hi mom'' at the start of the segment:
+.EX
+	% echo -n hi mom > /mnt/segment/example/data
+.EE
+.PP
+Attach the segment to a process:
+.EX
+{
+	ulong va;
+
+	va = segattach(0, "example", 0, 0);
+}
+.EE
+.SH "SEE ALSO
+.IR segattach (2)
+.SH SOURCE
+.B /sys/src/9/port/devsegment.c
diff --git a/static/plan9-4e/man3/srv.3 b/static/plan9-4e/man3/srv.3
new file mode 100644
index 00000000..820c849d
--- /dev/null
+++ b/static/plan9-4e/man3/srv.3
@@ -0,0 +1,74 @@
+.TH SRV 3 
+.SH NAME
+srv \- server registry
+.SH SYNOPSIS
+.nf
+.B bind #s /srv
+
+.BI #s/ service1
+.BI #s/ service2
+ ...
+.fi
+.SH DESCRIPTION
+The
+.I srv
+device provides a one-level directory holding
+already-open channels to services.
+In effect,
+.I srv
+is a bulletin board on which processes may post open file descriptors
+to make them available to other processes.
+.PP
+To install a channel, create
+a new file such as
+.B /srv/myserv
+and then write a text string (suitable for
+.IR strtoul ;
+see
+.IR atof (2))
+giving the file descriptor number of an open file.
+Any process may then open
+.B /srv/myserv
+to acquire another reference to the open file that was registered.
+.PP
+An entry in
+.I srv
+holds a reference to the associated file even if no process has the
+file open.  Removing the file from
+.B /srv
+releases that reference.
+.PP
+It is an error to write more than one number into a server file,
+or to create a file with a name that is already being used.
+.SH EXAMPLE
+To drop one end of a pipe into
+.BR /srv ,
+that is, to create a named pipe:
+.IP
+.EX
+int fd, p[2];
+char buf[32];
+
+pipe(p);
+fd = create("/srv/namedpipe", OWRITE, 0666);
+fprint(fd, "%d", p[0]);
+close(fd);
+close(p[0]);
+fprint(p[1], "hello");
+.EE
+.PP
+At this point, any process may open and read
+.B /srv/namedpipe
+to receive the
+.B hello
+string.  Data written to
+.B /srv/namedpipe
+can be received by executing
+.IP
+.EX
+read(p[1], buf, sizeof buf);
+.EE
+.PP
+in the above process.
+.SH SOURCE
+.B /sys/src/9/port/devsrv.c
diff --git a/static/plan9-4e/man3/ssl.3 b/static/plan9-4e/man3/ssl.3
new file mode 100644
index 00000000..2b3944d1
--- /dev/null
+++ b/static/plan9-4e/man3/ssl.3
@@ -0,0 +1,124 @@
+.TH SSL 3 
+.SH NAME
+ssl \- SSL record layer
+.SH SYNOPSIS
+.nf
+.B bind -a #D /net
+
+.B /net/ssl/clone
+.BI /net/ssl/ n 
+.BI /net/ssl/ n /ctl
+.BI /net/ssl/ n /data
+.BI /net/ssl/ n /encalgs
+.BI /net/ssl/ n /hashalgs
+.BI /net/ssl/ n /secretin
+.BI /net/ssl/ n /secretout
+.fi
+.SH DESCRIPTION
+The SSL device provides the interface to the Secure Socket Layer
+device implementing the record layer protocol of SSLv2
+(but not the handshake protocol, which is responsible for
+mutual authentication and key exchange.)
+The
+.I ssl
+device can be thought of as a filter providing optional encryption
+and anti-tampering.
+.PP
+The top level directory contains a
+.B clone
+file and subdirectories numbered from zero to the number of connections
+configured.
+Opening the
+.B clone
+file reserves a connection.  The file descriptor returned from the
+.IR open (2)
+will point to the control file,
+.BR ctl ,
+of the newly allocated connection.  Reading the
+.B ctl
+file returns a text
+string representing the number of the
+connection.
+.PP
+A connection is controlled by writing text strings to the associated
+.B ctl
+file.  After a connection has been established data may be read from
+and written to the data file.
+.PP
+The SSL protocol provides a stream connection that preserves
+.BR read / write
+boundaries.  As long as reads always specify buffers that are
+of equal or greater lengths than the writes at the other end of the
+connection, one write will correspond to one read.
+.PP
+Options are set by writing control messages to the
+.B ctl
+file of the connection.
+.PP
+The following control messages are supported:
+.TP
+.BI fd \ open-file-descriptor
+Run the SSL protocol over the existing file descriptor.
+.TP
+.BI alg \ cryptoalgs
+Connections start in
+.B alg clear
+which means no encryption or digesting.
+Writing
+.B alg sha
+to the control file turns on SHA-1 digest authentication
+for the data channel.
+Similarly, writing
+.B alg rc4_128
+enables encryption.
+Both can be turned on at once by
+.BR "alg sha rc4_128" .
+The digest mode
+.B sha
+may be replaced by
+.BR md5 .
+The encryption mode
+.B rc4_128
+may be replaced by
+.BR rc4_40 ,
+.BR rc4_128 ,
+.BR rc4_256 ,
+.BR des_40_ecb ,
+.BR des_40_cbc ,
+.BR des_56_ecb ,
+and
+.BR des_56_cbc .
+The mode may be changed at any time during the connection.
+.TP
+.BI secretin \ base64-secret
+The secret for decrypting and authenticating incoming messages
+can be specified either as a base64 encoded string by writing to the
+control file, or as a binary byte string using the interface below.
+.TP
+.BI secretout \ base64-secret
+The secret for encrypting and hashing outgoing messages
+can be specified either as a base64 encoded string by writing to the
+control file, or as a binary byte string using the interface below.
+.PP
+Before enabling digesting or encryption, shared secrets must be agreed upon with
+the remote side, one for each direction of transmission,
+and loaded as shown above or by writing to the files
+.I secretin
+and
+.IR secretout .
+If either the incoming or outgoing secret is not specified, the other secret
+is assumed to work for both directions.
+.PP
+The encryption and hash algoritms actually included in the kernel
+may be smaller than the set presented here.  Reading
+.I encalgs
+and 
+.I hashalgs
+will give the actual space-separated list of algorithms implemented.
+.SH "SEE ALSO"
+.IR listen (8),
+.IR dial (2)
+.SH SOURCE
+.B /sys/src/9/port/devssl.c
+.SH BUGS
+Messages longer than 4096 bytes are truncated.
diff --git a/static/plan9-4e/man3/tls.3 b/static/plan9-4e/man3/tls.3
new file mode 100644
index 00000000..f38fe283
--- /dev/null
+++ b/static/plan9-4e/man3/tls.3
@@ -0,0 +1,272 @@
+.TH TLS 3 
+.SH NAME
+tls \- TLS1 and SSL3 record layer
+.SH SYNOPSIS
+.nf
+.B bind -a #a /net
+
+.B /net/tls/clone
+.B /net/tls/encalgs
+.B /net/tls/hashalgs
+.BI /net/tls/ n 
+.BI /net/tls/ n /ctl
+.BI /net/tls/ n /data
+.BI /net/tls/ n /hand
+.BI /net/tls/ n /stats
+.BI /net/tls/ n /status
+.fi
+.SH DESCRIPTION
+The TLS device implements the record layer protocols
+of Transport Layer Security version 1.0 and Secure Sockets Layer version 3.0.
+It does not implement the handshake protocols, which are responsible for
+mutual authentication and key exchange.
+The
+.I tls
+device can be thought of as filters providing optional encryption and anti-tampering.
+.PP
+The top level directory contains a
+.B clone
+file and subdirectories numbered from zero through at least the last active filter.
+Opening the
+.B clone
+file reserves a filter.
+The file descriptor returned from the
+.IR open (2)
+will point to the control file,
+.BR ctl ,
+of the newly allocated filter.
+Reading the
+.B ctl
+file returns a text string containing the number of the filter directory.
+.PP
+The filter initially cannot be used to pass messages
+and will not encrypt or digest messages.
+It is configured and controlled by writing commands to
+.BR ctl .
+.PP
+The following commands are supported:
+.TP
+.BI fd \ open-fd\ vers
+Pass record messages over the communications channel
+.IR open-fd .
+Initially, outgoing messages use version
+.I vers
+format records, but incoming messages of either version are accepted.
+Valid versions are
+.B 0x300
+for SSLv3.0 and
+.B 0x301
+for TLSv1.0 (which could be known as SSLv3.01.)
+This command must be issued before any other command
+and before reading or writing any messages;
+it may only be executed once.
+.TP
+.BI version \ vers
+Use
+.I vers
+format records for all future records,
+both outgoing and incoming.
+This command may only be executed once.
+.TP
+.BI secret \ hashalg\ encalg\ isclient\ secretdata
+Set up the digesting and encryption algorithms and secrets.
+.I Hashalg
+and
+.I encalg
+must be algorithm names returned by the corresponding files.
+.I Secretdata
+is the base-64 encoded (see
+.IR encode (2))
+secret data used for the algorithms.
+It must contain at least enough data to populate the
+secrets for digesting and encrypting.
+These secrets are divided into three categories: digest secrets, keys, and initialization vectors.
+The secrets are packed in this order, with no extra padding.
+Within each category, the secret for data traveling from the client to the server comes first.
+The incoming and outgoing secrets are automatically selected by devtls based on the
+.I isclient
+argument, which must be non-zero for the client of the TLS handshake,
+and zero for the server.
+.br
+This command must be issued after
+.BR version ,
+and may be issued more than once.
+At least one new
+.I secret
+command must be issued before each
+.I changecipher
+command; similarly, at least one new
+.I secret command
+must precede each incoming changecipher message.
+.TP
+.BI changecipher
+Enable outgoing encryption and digesting as configured by the previous
+.I secret
+command.
+This command sends a
+.I changecipher
+message.
+.TP
+.BI opened
+Enable data messages.
+This command may be issued any number of times,
+although only the first is significant.
+It must follow at least one successful
+.I changecipher
+command.
+.TP
+.BI alert \ alertno
+Send an alert message.
+.I Alertno
+may be a valid alert code for either SSLv3.0 or TLSv1.0,
+and is mapped to an appropriate code for the protocol in use.
+If it is a fatal alert, the filter is set into an error state.
+.PP
+Application messages and handshake messages are communicated using
+.I data
+and
+.IR hand ,
+respectively.
+Only one
+.IR open (2)
+of
+.I hand
+is allowed at a time.
+.PP
+Any record layer headers and trailers are inserted and
+stripped automatically, and are not visible from the outside.
+The device tries to synchronize record boundaries with reads and writes.
+Each read will return data from exactly one record,
+and will return all of the data from the record as long as
+the buffer is big enough.
+Each write will be converted into an integral number of records,
+with all but potentially the last being maximal size.
+The maximum record length supported is 16384 bytes.
+This behavior is not specified in the protocols,
+and may not be followed by other implementations.
+.PP
+If a fatal alert message is received, or a fatal
+.I alert
+command issued, the filter is set into an error state.
+All further correspondence is halted,
+although some pending operations may not be terminated.
+Operations on
+.I data
+will fail with a
+.BR "'tls error'" ,
+and operations on
+.I hand
+will fail with a textual decoding of the alert.
+The current non-fatal alert messages are
+.BR "'close notify'" ,
+.BR "'no renegotiation'" ,
+and
+.BR "'handshake canceled by user'" .
+Receipt of one of these alerts cause the next read on
+.I hand
+to terminate with an error.
+If the alert is
+.BR "'close notify'",
+all future reads will terminate with a
+.B "tls hungup"
+error.
+A
+.B "'close notify'"
+.I alert
+command will terminate all future writes or reads from
+.I data
+with a
+.B "'tls hungup'"
+error.
+.PP
+If an error is encountered while reading or writing
+the underlying communications channel, the error is returned
+to the offending operation.
+If the error is not
+.BR "'interrupted'" ,
+the filter is set into the error state.
+In this case, all future operations on
+.I hand
+will fail with a
+.BR "'channel error'" .
+.PP
+When all file descriptors for a filter have been closed,
+the session is terminated and the filter reclaimed for future use.
+A
+.B "'close notify'"
+alert will be sent on the underlying communications channel
+unless one has already been sent or the filter is in the error state.
+.PP
+Reading
+.I stats
+or
+.I status
+returns information about the filter.
+Each datum is returned on a single line of the form
+.IB tag ": " data .
+.I Stats
+returns the number of bytes communicated by the
+.B data
+and
+.B hand
+channels.
+The four lines returned are tagged by, in order,
+.BR DataIn ,
+.BR DataOut ,
+.BR HandIn ,
+and
+.BR HandOut .
+.I Status
+returns lines following tags:
+.BR State ,
+.BR Version ,
+.BR EncIn ,
+.BR HashIn ,
+.BR NewEncIn ,
+.BR NewHashIn ,
+.BR EncOut ,
+.BR HashOut ,
+.BR NewEncOut ,
+and
+.BR NewHashOut .
+.BR State 's
+value is a string describing the status of the connection,
+and is one of the following:
+.BR 'Handshaking' ,
+.BR 'Established' ,
+.BR 'RemoteClosed' ,
+.BR 'LocalClosed' ,
+.BR 'Alerting' ,
+.BR 'Errored' ,
+or
+.BR 'Closed' .
+.BR Version 's
+give the hexadecimal record layer version in use.
+The
+.B Enc
+and
+.B Hash
+fields return name of the current algorithms in use
+or ready to be used, if any.
+.PP
+Reading
+.I encalgs
+and 
+.I hashalgs
+will give the space-separated list of algorithms implemented.
+This will always include
+.BR clear ,
+meaning no encryption or digesting.
+Currently implemented encryption algorithms are
+.B 'rc4_128'
+and
+.BR '3des_ede_cbc' .
+Currently implemented hashing algorithms are
+.B 'md5'
+and
+.BR 'sha1' .
+.SH "SEE ALSO"
+.IR listen (8),
+.IR dial (2)
+.SH SOURCE
+.B /sys/src/9/port/devtls.c
diff --git a/static/plan9-4e/man3/uart.3 b/static/plan9-4e/man3/uart.3
new file mode 100644
index 00000000..b4504610
--- /dev/null
+++ b/static/plan9-4e/man3/uart.3
@@ -0,0 +1,97 @@
+.TH UART 3 
+.SH NAME
+uart, eia \- serial communication control
+.SH SYNOPSIS
+.nf
+.B bind -a #t /dev
+
+.B /dev/eia0
+.B /dev/eia0ctl
+.B /dev/eia0status
+.B /dev/eia1
+.B /dev/eia1ctl
+.B /dev/eia1status
+\&...
+.fi
+.SH DESCRIPTION
+.PP
+The serial line devices serve a one-level directory,
+giving access to the serial ports.
+Device
+.I n
+is accessed through
+.BI eia n
+(the data file),
+.BI eia n ctl
+(the control file), and
+.BI eia n status
+(the read-only status file).
+Reads of the data file will block until at least one byte is available.
+The
+control file
+configures the port.
+It accepts the following commands:
+.TP
+.BI b n
+Set the baud rate to
+.IR n .
+.TP
+.BI d n
+Set DTR if
+.I n
+is non-zero;
+else clear it.
+.TP
+.BI k n
+Send a break lasting
+.I n
+milliseconds.
+.TP
+.BI r n
+Set RTS if
+.I n
+is non-zero;
+else clear it.
+.TP
+.BI m n
+Obey modem CTS signal if
+.I n
+is non-zero;
+else clear it.
+.TP
+.BI i n
+Enable input FIFO if
+.I n
+is non-zero;
+else disable.
+.TP
+.BI p c
+Set parity to odd if
+.I c
+is
+.BR o ,
+to even if
+.I c
+is
+.BR e ;
+else set no parity.
+.TP
+.BI s n
+Set number of stop bits to
+.IR n .
+Legal values are 1 or 2.
+.TP
+.BI l n
+Set number of bits per byte to
+.IR n .
+Legal values are 5, 6, 7, or 8.
+.PP
+The status
+files contain a textual representation of the status of the line, in the format of the
+commands used on the
+control
+file.
+.SH SOURCE
+.B /sys/src/9/port/devuart.c
+.br
+.B /sys/src/9/*/uart*.c
diff --git a/static/plan9-4e/man3/usb.3 b/static/plan9-4e/man3/usb.3
new file mode 100644
index 00000000..587b7a30
--- /dev/null
+++ b/static/plan9-4e/man3/usb.3
@@ -0,0 +1,235 @@
+.TH USB 3 
+.SH NAME
+usb \- USB Host Controller Interface
+.SH SYNOPSIS
+.nf
+.B bind -a #U /dev
+
+.BI /dev/usb m
+.BI /dev/usb m /new
+.BI /dev/usb m /port
+.BI /dev/usb m / n 
+.BI /dev/usb m / n /ctl
+.BI /dev/usb m / n /status
+.BI /dev/usb m / n /setup
+.BI /dev/usb m / n /ep k\fLdata
+\&...
+
+.fi
+.SH DESCRIPTION
+The Universal Serial Bus is a popular bus for connecting slow and medium speed
+devices, such as mice, keyboards, printers, and scanners to a PC.  It is
+a four-wire tree-shaped bus that provides both communication and (limited)
+power to devices.  Branching points in the tree are provided by devices
+called
+.IR hubs .
+.PP
+Most PCs have a two-slot hub built in, accommodating two USB devices.  To
+attach more devices, one or more hubs have to be plugged in to the USB
+slots of the PC.  The topology of the network is a tree with at most
+127 nodes, counting both internal and leaf nodes.
+.PP
+The USB bus is fully controlled by the host; all devices are polled.
+Hubs are passive in the sense that they do not poll the devices attached
+to them.  The host polls those devices and the hubs merely route the
+messages.
+.PP
+When a device is attached, the host queries it to determine its type
+and its speed.  The querying process is standardized.  The first level
+of querying is the same for all devices, the next is somewhat specialized
+for particular classes of devices (such as mice, keyboards, or audio devices).
+Specialization continues as subclasses and subsubclasses are explored.
+.PP
+For each connected device there is a directory in
+.BI #U/usb n\fR.
+Reading
+.BI #U/usb n /*/status
+yields the state, class, subclass and proto of each device in the
+first line.  The remaining lines give the state of each of the
+interfaces.
+.PP
+To find a mouse, for example, scan the status files for the line
+.IP
+.EX
+.BR "Enabled 0x020103"
+.EE
+.PP
+A mouse belongs to class 3 (in the least significant byte),
+.IR "human interface device" ,
+subclass 1,
+.IR boot ,
+proto 2,
+.I mouse
+(proto 1 would be the keyboard).
+USB class, subclass and proto codes can be found on
+.BR www.usb.org .
+.PP
+The control interface for each device is
+.I "``endpoint 0''"
+and is named
+.BI #U/usb n /*/setup \fR.
+The control interface of the device is accessed by reading and writing
+this file.
+.PP
+There is a separate
+.I "control interface
+named
+.BI #U/usb n /*/ctl
+which is used to configure the USB device
+.IR driver .
+By writing to this
+file, driver endpoints can be created and configured for communication with a
+device's data streams.  A mouse, for example, has one control interface
+and one data interface.  By communicating with the control interface,
+one can find out the device type (i.e., `mouse'), power consumption, number
+on interfaces, etc.
+.IR Usbd (4)
+will extract all this information and, in verbose mode, print it.
+.PP
+By sending an `endpoint message' to the
+.I ctl
+file, new driver endpoints can be created.  The syntax of these messages
+is
+.PP
+.B ep
+.I n
+.B bulk
+.I "mode maxpkt nbuf
+.PP
+or
+.PP
+.B ep
+.I "n period mode samplesize hz
+.PP
+The first form configures a non-real-time stream, the second an
+.I isochronous
+(real-time) stream.
+In both forms,
+.I n
+is the endpoint to be configured, and
+.I mode
+is
+.B r
+for read only, or
+.B w
+for reading and writing.
+In the first form,
+.I maxpkt
+is the maximum packet size to be used (between 1 and 2048),
+and
+.I nbuf
+is the number of buffers to be allocated by the driver.
+.PP
+In the second form,
+.I period
+is the number of milliseconds between packets.  This number is usually
+dictated by the device.  It must be between 1 and 1000.
+The
+.I samplesize
+is the size in bytes of the data units making up packets, and
+.I hz
+is the number of data units transmitted or received per second.
+.PP
+The data rate is thus
+.IR hz × samplesize
+bytes per second, and the packet size used will vary between
+⌊(\f2period\fP×\f2hz\fP)/1000⌋×\f2samplesize\fP
+and
+⌈(\f2period\fP×\f2hz\fP)/1000⌉×\f2samplesize\fP.
+.PP
+The mouse, which produces 3-byte samples, is configured with
+.BR "ep 1 bulk r 3 32" :
+endpoint 1 is configured for non-real-time read-only 3-byte messages
+and allows 32 of them to be outstanding.
+.PP
+A usb audio output device at 44.1 KHz, 2 channels, 16-bit samples, on endpoint
+4 will be configured with
+.BR "ep 4 1 w 4 44100" .
+.PP
+If the configuration is successful, a file named
+.BI ep n data
+is created which can be read and/or written depending on
+configuration.  Configuration is not allowed when the data endpoint
+is open.
+.PP
+Forward
+.I seek
+operations on isochronous endpoints
+can be used to start the I/O at a specific time.
+The usb status file provides information that can be used to map file
+offsets to points in time:  For each endpoint, the status file produces a line
+of the form:
+.PP
+.B "4 0x000201 \f2nnn\fP bytes \f2nnn\fP blocks
+.PP
+The fields are, from left to right,
+endpoint number, class/subclass/proto (as a six-digit hex number with class in the
+least significant byte), number of bytes read/written, number of blocks read/written.
+.PP
+For isochronous devices only, an additional line is produced of the
+form:
+.PP
+.B "bufsize \f2s\fP buffered \f2b\fP offset \f2o\fP time \f2t\fP
+.PP
+.I S
+is the size of the DMA operations on the device (i.e., the minimum useful size
+for reads and writes),
+.I b
+is the number of bytes currently buffered for input or output, and
+.I o
+and
+.I t
+should be interpreted to mean that byte offset
+.I o
+was/will be reached at time
+.I t
+(nanoseconds since the epoch).
+.PP
+To play or record samples exactly at some predetermined time, use
+.I o
+and
+.I t
+with the sampling rate to calculate the offset to seek to.
+.PP
+The number of bytes buffered can also be obtained using
+.IR stat (2)
+on the endpoint file.  See also
+.IR audio (3).
+.sp
+.SH FILES
+.TF "#U/usb n /*/status"
+.TP
+.BI #U/usb n /*/status
+USB device status file, class, subclass and proto are found in line one
+.TP
+.BI #U/usb n /*/ctl
+USB
+.I driver
+control file, used to create driver endpoints, control debugging, etc.
+.TP
+.BI #U/usb n /*/setup
+USB
+.I device
+control file, used to exchange messages with a device's control channel.
+.B setup
+may be viewed as a preconfigured
+.B ep0data
+file.
+.TP
+.BI #U/usb n /*/ep k data
+USB device data channel for the
+.IR k 'th
+configuration.
+.SH "SEE ALSO"
+.IR usb (4),
+.IR usbd (4),
+.IR plan9.ini (8)
+.SH BUGS
+OpenHCI USB cards are not yet supported.
+.PP
+The interface for configuring endpoints is at variance with the standard.
+.PP
+The notion that the endpoints themselves have a class and subclass
+is a distortion of the standard.
+It would be better to leave all handling of the notions of class to the
+user-level support programs, and remove it from the driver.
diff --git a/static/plan9-4e/man3/vga.3 b/static/plan9-4e/man3/vga.3
new file mode 100644
index 00000000..a2fe3dee
--- /dev/null
+++ b/static/plan9-4e/man3/vga.3
@@ -0,0 +1,209 @@
+.TH VGA 3 
+.SH NAME
+vga \- VGA controller device
+.SH SYNOPSIS
+.nf
+.B bind #v /dev
+
+.B /dev/vgactl
+.fi
+.SH DESCRIPTION
+The VGA device allows configuration of a graphics controller
+on a PC.
+.B Vgactl
+allows control over higher-level settings such as display height, width, depth,
+controller and hardware-cursor type.
+Along with the I/O-port registers
+provided by
+.IR arch (3),
+it is used to implement configuration and setup of VGA controller cards.
+This is usually performed by
+.IR vga (8).
+.PP
+Writing strings to 
+.B vgactl
+configures the VGA device.
+The following are valid commands.
+.TP
+.BI size " X" x Y x "Z chan"
+Set the size of the screen image to be
+.I X 
+pixels wide
+and
+.I Y 
+pixels high.
+Each pixel is 
+.I Z 
+bits as specified by 
+.IR chan ,
+whose format is described in
+.IR image (6).
+.TP
+.BI actualsize " X" x Y
+Set the physical size of the display to be
+.I X
+pixels wide by
+.I Y 
+pixels high.
+This message is optional;
+it is used to implement panning and to accommodate
+displays that require the in-memory screen image
+to have certain alignment properties.
+For example, a 1400x1050 screen with a 1408x1050 in-memory image
+will use 
+.B "size 1408x1050
+but
+.BR "actualsize 1400x1050" .
+.TP
+.BI panning " mode"
+Depending on whether
+.I mode
+is 
+.B on
+or
+.BR off ,
+enable or disable panning in a virtual screen.
+If panning is on and the screen's
+.B size
+is larger than its
+.BR actualsize ,
+the displayed portion of the screen will pan to follow the mouse.
+Setting the panning mode after the first attach of the
+.B #i
+driver has no effect.
+.TP
+.BI type " ctlr"
+Set the type of VGA controller being used.
+.I Ctlr
+is one of 
+.BR ark200pv ,
+.BR clgd542x ,
+.BR clgd546x ,
+.BR ct65545 ,
+.BR cyber938x ,
+.BR hiqvideo ,
+.BR mach64xx ,
+.BR mga2164w ,
+.BR neomagic ,
+.BR s3 ,
+and
+.BR t2r4 .
+.IP
+Note that this list does not indicate the full set of VGA chips
+supported. For example,
+.B s3
+includes the 86C801/5, 86C928, Vision864, and Vision964.
+It is the job of
+.IR vga (8)
+to recognize which particular chip is being used and to initialize it
+appropriately.
+.TP
+.BI hwgc " gc"
+Set the type of hardware graphics cursor being used.
+.I Gc
+is one of
+.BR ark200pvhwgc ,
+.BR bt485hwgc ,
+.BR clgd542xhwgc ,
+.BR clgd546xhwgc ,
+.BR ct65545hwgc ,
+.BR cyber938xhwgc ,
+.BR hiqvideohwgc ,
+.BR mach64xxhwgc ,
+.BR mga2164whwgc ,
+.BR neomagichwgc ,
+.BR rgb524hwgc ,
+.BR s3hwgc ,
+.BR t2r4hwgc ,
+.BR tvp3020hwgc ,
+and
+.BR tvp3026hwgc .
+A value of
+.B off
+disables the cursor.
+There is no software cursor.
+.TP
+.BI palettedepth " d"
+Set the number of bits of precision used by the 
+VGA palette to 
+.IR d ,
+which must be either 
+.B 6
+or
+.BR 8 .
+.TP
+.B blank
+Blank the screen.
+This consists of setting the hardware
+color map to all black as well as, on some controllers, setting the
+VGA hsync and vsync signals so as to turn off
+VESA DPMS-compliant monitors.
+The screen also blanks after 30 minutes of inactivity.
+The screen can be unblanked by moving the mouse.
+.TP
+.BI blanktime " minutes"
+Set the timeout before the
+screen blanks; the default is 30 minutes.
+If
+.I minutes
+is zero, blanking is disabled.
+.TP
+.BI hwaccel " mode"
+Depending on whether
+.I mode
+is 
+.B on
+or
+.BR off ,
+enable or disable whether hardware acceleration
+(currently for rectangle filling and moving)
+used by the graphics engine.
+The default setting is
+.BR on .
+.TP
+.BI hwblank " mode"
+Depending on whether
+.I mode
+is
+.B on
+or
+.BR off ,
+enable or disable the use of DPMS blanking
+(see
+.B blank
+above).
+.TP
+.BI linear " size align"
+Use a linear screen aperture of size
+.I size
+aligned on an
+.IR align -byte
+boundary.
+.TP
+.B drawinit
+Initialize the graphics hardware.
+This must be sent after setting the
+.BR type .
+.PP
+Reading
+.B vgactl
+returns the current settings, one per line.
+.SH EXAMPLES
+The following disables hardware acceleration.
+.IP
+.EX
+echo -n 'hwaccel off' >/dev/vgactl
+.EE
+.SH SOURCE
+.B /sys/src/9/pc/devvga.c
+.SH SEE ALSO
+.IR arch (3),
+.IR vga (8)
+.SH BUGS
+There should be support for the hardware graphics cursor on the
+.B clgd54[23]x
+VGA controller chips.
+.PP
+The hardware graphics cursor on the
+.B et4000
+does not work in 2x8-bit mode.
author	Jacob McDonnell <jacob@jacobmcdonnell.com>	2026-04-26 16:38:00 -0400
committer	Jacob McDonnell <jacob@jacobmcdonnell.com>	2026-04-26 16:38:00 -0400
commit	97d5c458cfa039d857301e1ca7d5af3beb37131d (patch)
tree	b460cd850d0537eb71806ba30358840377b27688 /static/plan9-4e/man3
parent	b89dc2331a50c63f8b33272a5c4c61ab98abdaa3 (diff)