The kernel tables driver is a character special
pseudo-device providing access to various strings (such as
console messages) and system tables (such as all
processes). Commands such as
use this device to avoid having to understand how all of
kernel memory is laid out.
The strings are described in
this manual page describes only the system tables.
Each table comprises zero or more entries
(elements). An element is usually a structure
defined in a system header file. The elements in a given
table do not have to be the same size, and in this release
of the Operating System, all tables are read-only. (Some
of the strings are writable.)
The minor device number determines which kernel table is read.
There are two read modes:
returns the next element in the table. If the number of
bytes requested is smaller than that element's size, the
trailing end of the element is not read. If the number of
bytes is larger, only the bytes comprising the element are
read. If the current position in the table is not at the
start of an element, it is automatically advanced to the
start of the subsequent element before any bytes are read.
This is the default mode for most tables.
Each read returns the requested number of bytes
starting at the current position in the table but not
extending beyond its end. The data read may start or end
in the middle of an element, and may contain part or all of
one or more elements. This mode is used when the device is
and O_SYNC is specified, or a subsequent call to
sets the O_SYNC mode. For some tables (and all
the strings) this is the default and only read mode.
The end of the table is treated as end-of-file
(read returns zero). Reading tables is
non-blocking and non-destructive.
The element-by-element read mode is intended to
enhance both forward and backward compatibility. For
example, should the eproc structure be extended
in the future, the extension will probably be implemented
by adding new fields to the end. An application reading
/dev/string/eproc element-by-element and compiled
with the older smaller eproc will only read the
bytes in each element that it knows about on both old and
An application built with the new larger eproc
will only read the bytes which exist on the system. The
unread portion of the structure should be zeroed if the
application read less bytes than intended; the application
should then still work on both old and new systems.
The current position in the table is set by
Note that the current position is the offset in bytes from
the start of the table; it is not the index of an element
in the table.
commands are provided (defined in <sys/tab.h>;
these commands return information about the table in the
argument arg to ioctl):
Returns the smallest possible size in bytes of an element.
Returns the largest possible size in bytes of an element.
If all the elements in the table are the same size,
this returns the same value as both
Otherwise, it fails with error
Returns the number of elements currently in the table,
or the current size of the string.
Returns the maximum possible number of elements this table may contain,
or the maximum possible size of this string.
Returns the kernel virtual address of the start of the element containing
the file offset (lseek position) arg.
Returns the file offset of the start of the element containing kernel virtual
The following tables support both read modes:
S5/AFS i-node cache
Outstanding file locks
Run averages scaled by 256.0
+ See ``Warning'' for details of the security considerations.
The following tables also support both read modes;
there is one element for each CPU:
Paging and swapping
The following tables (and all the strings)
support byte-stream read mode only:
The following codes are returned in errno on error:
The minor device number is not defined;
an invalid kernel virtual address was specified with
TAB_ADDR_TO_SEEK; an attempt was made to write
to a string starting at a position beyond its maximum size or to
read bytes starting at a position beyond the table's
An attempt was made to open a read-only device for writing; an
ioctl command not supported by this device was attempted
(such as requesting the TAB_ELEMENT_SIZE
of a string or of a table containing variable-sized elements).
The table is corrupted or not present in this configuration of the system.
An unknown ioctl command was attempted.
A read or write specified an invalid buffer
address or size.
The write would block and O_NONBLOCK is set
for the file descriptor.
Table elements are usually binary data;
attempting to display them directly on the terminal
may result in a corrupted display or locked keyboard.
Programs such as ps interpret and display elements in
a safe and readable format.
The special file
/dev/table/clist is not normally present as it presents a
significant security risk (by making it too easy to steal sensitive
information). Most devices (particularly those in the first
table above) should be carefully protected. Normally they are owned
by root, group mem,
with permissions 440 (no access to others).
This is especially important as ioctl and
read are not restricted to root.
If the device can be opened then it may be read and commands issued.
Commands which use these devices should be
Such commands typically should be part of the mem
so individual users can be granted or denied full or partial access.
defines the ioctl commands listed in the ``Description''
directory containing the special files used by tab
directory containing the special files described in the
internal tab data structures and configuration definitions
internal table describing each tab special file (minor
device numbers less than 128 decimal are reserved and should not