jbc@ut-sally.UUCP (08/07/83)
- 7 -
spooling facility.
The Berkeley font library seems rather more extensive
than that provided with System V. These fonts are used by
the Versatec filters to simulate the mounted fonts of a
C/A/T phototypesetter, the standard destination device for
non-device independent _t_r_o_f_f.
The best version of _t_r_o_f_f comes with neither of these
systems. This is the Typesetter Independent Troff (TITroff)
package (commonly known as DITroff, for Device Independent
Troff). It is available separately from Western Electric
and includes useful graphics packages (_p_i_c and _i_d_e_a_l) which
can be used to augment the basic typesetting facilities.
In 4.2, the printer spooling facilities have hooks for
TITroff so that the package can be used immediately when
obtained (though TITroff itself is still distributed
separately by Western Electric). See below under _P_r_i_n_t_i_n_g.
The Writer's Workbench facilities _s_t_y_l_e, _d_i_c_t_i_o_n and
_e_x_p_l_a_i_n, which analyze surface characteristics and
readability of written text, are supplied with 4.1C. This
is apparently a Bell Research Group package and is available
separately from Western Electric. _S_t_y_l_e ignores macros from
-ms, -me, -mm, and -ma, although the manual page only
mentions -ms and -mm.
4.2 also includes an improved _r_e_f_e_r and _b_i_b.
2.1.5 _G_r_a_p_h_i_c_s 4.1C has rather rudimentary graphics
capability.
In contrast, System V has the PWB graphics package,
including _g_e_d, a graphical editor, and numerous data
generation, transformation, and display commands. This
graphics capability has been used extensively in conjunction
with the accounting packages.
2.1.6 _I_n_g_r_e_s The relational database system Ingres is part
of 4.1C, and a commercial version of Ingres is available for
4BSD. We do not know if it will work under System V.
2.1.7 _T_e_x_t__e_d_i_t_o_r_s Both systems have the traditional UNIX
editor, _e_d, and System V has adopted the Berkeley _v_i
(screen) and _e_x (line) editors, which are also of course in
4.1C.
System V documents a new screen editor named _s_e but it
was not included on the distribution. Apparently it does
not utilize the terminal independence capability provided by
- 8 -
_t_e_r_m_c_a_p but, rather, uses its own terminal description file,
/usr/lib/se.term (also not on the distribution).
Recent versions of the Rand Editor _e and UNIX Emacs can
presumably be made to run correctly on System V, although
this was not our experience.
Though the distributed versions of the two commonly
available versions of _E_m_a_c_s have problems running on 4.1C,
since they still attempt to use the obsolete MPX IPC
facility, at least one (Gosling's) has already been adapted
at Berkeley to use the superior Berkeley IPC mechanism. (No
problems were noted running them under 4.1.)
2.1.8 _E_l_e_c_t_r_o_n_i_c__m_a_i_l System V has a rudimentary mail
system, not much altered from V7 or System III.
4.1C has a more elaborate one, with most of the
commonly useful mail functions. 4.1C actually provides two
mail delivery routes, one unprotected and the other
encrypted. There is a new mail delivery program called
_s_e_n_d_m_a_i_l (a descendant of the _d_e_l_i_v_e_r_m_a_i_l of 4.1) which
provides a central mail handling system capable of dealing
with multiple networks and addressing formats.
The Rand _m_h system can be used as an alternative front
end to the Berkeley mail system and will be provided with
4.2 as user contributed software. Some people use _E_m_a_c_s for
this purpose.
We understand that the MMDF mail system from the
University of Maryland can be used with either the Bell or
the Berkeley version of the Unix System but we have no
direct experience with it.
2.1.9 _P_r_i_n_t_i_n_g The _l_p_r command and _l_p_d daemon have been
modified in 4.1C to use the file /etc/printcap (similar to
/etc/termcap) to define the characteristics of the various
printers attached to a system. Printers may be added or
deleted without changing the programs and output filter
programs are supported on a per-device basis. It is
possible to treat a printer on another machine as if it were
local (from the user's viewpoint) and have _l_p_d ship files
across a network to it. The Berkeley IPC mechanism is used
for queueing requests, editing the queue, monitoring queue
activity, etc.
In 4.2, _l_p_r, etc., provide support for various raster
devices (such as Varian or Versatec), laser printers (such
as Imagen), and numerous ordinary printers. Specifying a
new type of device in /etc/printcap is relatively easy.
- 9 -
The user specifies a printer either as a command line
option to _l_p_r or in the PRINTER environment variable.
The System V _l_p_r is considered obsolete and has been
replaced by a spooling system similar in flavor to that
provided with 4.1C but without the extensive network
support. The LP-11 is still considered the canonical
printing device, although a particular destination may be
specified by the LPDEST environment variable.
_M_D_Q_S (Multiple Device Queueing System) is available
from BRL and provides support for queueing output to a
variety of different devices.
2.2 System Calls
The user interface to most of the system calls is the
same, i.e., the interface routines in the C library have the
same calling sequence, but the actual system call numbers
differ.
4.1C has introduced a number of new system calls, some
intended to eventually replace older ones completely. Many
of the older ones are now simulated by interface routines
that call the new, extended ones.
2.2.1 _V_f_o_r_k__a_n_d__f_o_r_k The _f_o_r_k system call in System V has
been changed to require only one pass through the process
table per invocation. A resulting improvement in performance
is claimed; however, we did not attempt to measure this.
4BSD includes the _v_f_o_r_k version of the _f_o_r_k system
call, which allows creation of a new process without the
need for copying the entire address space of the parent.
This makes sense in any environment where processes get very
large, as in the paging environment provided by 4.1C (see
comments below), but the implementation also imposes certain
restrictions which can mislead the unwary. Performance
statistics relating to the use of _v_f_o_r_k are widely available
and are outside the domain of this presentation.
2.9BSD has _v_f_o_r_k for the PDP-11. 4.3BSD will eliminate
the need for _v_f_o_r_k by a reimplementation of _f_o_r_k.
2.2.2 _R_e_b_o_o_t 4.1C has the _r_e_b_o_o_t system call, which is
quite convenient for persons engaged in system development
work. (See below on the _r_e_b_o_o_t command.)
System V documents a _r_e_b_o_o_t system call for the WECo
3B20S but nothing seems to be available for DEC machines.
- 10 -
2.2.3 _S_e_t_p_g_r_p 4.1C has elaborated the _s_e_t_p_g_r_p system call
to be more compatible with the job control functions of the
Cshell.
2.2.4 _G_r_o_u_p__s_y_s_t_e_m__c_a_l_l_s 4.1C has a new method of dealing
with the concept of groups and group ids (see the major
section below on _G_r_o_u_p_s).
2.2.5 _I_o_c_t_l_s The _i_o_c_t_l system call is essentially
identical in the two systems. The interesting differences
are in the terminal driver ioctls. Both drivers utilize the
``line discipline'' notion, allowing dynamic choice among
several protocols by the user process.
Berkeley offers several new features in 4.1C BSD over
the V7 terminal driver. Some of these are accessed as a new
line discipline (the ``new tty'' discipline), while a few
others are implemented as additional _i_o_c_t_l calls. There is
a line discipline in 4.1C for an RS232 interface to an
Hitachi tablet (this is undocumented). All of these are
useful features, but the tty ioctls have become somewhat
baroque.
The System V terminal driver is radically different
from the V7 one. Many functions which always should have
been orthogonal now are. As one example, the conversion of
carriage return to new line on input and of new line to
carriage return and line feed on output are now separately
controllable functions. Of course, this driver is
hopelessly incompatible with any previous one (except
System III) and with the Berkeley one. Additionally, there
is peripheral processor support for this line discipline in
the KMC-11B (see below).
System V also provides support for a virtual terminal
protocol, allowing drivers for selected terminals to be
compiled directly into the kernel. The terminal type may be
manipulated by two related _i_o_c_t_l_s, LDSETT and LDGETT; a type
specifier may then be passed to, say, _g_e_t_t_y (see below).
Unfortunately, this feature is not well-documented and it is
particularly advisable to study the terminal driver code and
the file /usr/include/termio.h.
2.2.6 _O_p_e_n__a_n_d__f_c_n_t_l The _o_p_e_n system call in System V
presents essentially the same interface as in System III but
now claims substantially improved performace due to the use
of a hashed inode table.
The _d_u_p_2 function of V7 and 4BSD has been replaced and
elaborated upon in System V by the _f_c_n_t_l system call. 4.1C
preserves the 32V FIOEXCL _i_o_c_t_l call to give control over
- 11 -
the inheritance of file descriptors across an _e_x_e_c; this is
provided by _f_c_n_t_l in Systems III and V. In conjunction with
an additional argument (mode) to the _o_p_e_n system call, _f_c_n_t_l
permits access to the O_NDELAY (non-blocking I/O)
capability. (The System III O_NDELAY bug appears to be
fixed in System V.)
4.1C uses an _i_o_c_t_l to set up non-blocking I/O but also
has various _o_p_e_n modes in addition to the old read and write
modes, plus the optional third argument for some of them.
Non-blocking opens, for instance, are supported.
4.2 has adopted exactly the same _o_p_e_n and _f_c_n_t_l
interfaces as System V, even going so far as to duplicate
the names of the mode bits. A different include file is
used for _o_p_e_n, however.
2.2.7 _4_._1_C__B_S_D__f_i_l_e__s_y_s_t_e_m__c_a_l_l_s 4.1C has a number of new
system calls affecting file I/O, in addition to the
modifications to the _o_p_e_n call noted above.
There are now system calls for _m_k_d_i_r, _r_m_d_i_r, and
_r_e_n_a_m_e.
Equivalents of old calls that apply to file descriptors
instead of file names have been added: _f_c_h_o_w_n and _f_c_h_m_o_d.
Symbolic links require some specific calls: _l_s_t_a_t,
_s_y_m_l_i_n_k, _r_e_a_d_l_i_n_k.
File truncation is supported by _t_r_u_n_c_a_t_e and _f_t_r_u_n_c_a_t_e,
and file locking by _f_l_o_c_k.
Scatter/gather I/O is supported by _r_e_a_d_v and _w_r_i_t_e_v.
The notion of ``file descriptor'' has been generalized
to include various other kinds of descriptors, such as
socket descriptors for use with IPC endpoints. Many of the
system calls, e.g. _c_l_o_s_e, that apply to file descriptors
also have meaning with other types of descriptors, and there
are several new system calls to deal with descriptors, such
as _g_e_t_d_t_a_b_l_e_s_i_z_e. The most generally useful of the new
descriptor system calls is _s_e_l_e_c_t, which is used to do
synchronous multiplexing of operations by determining (among
other things) whether it is possible to read or write data
on any of a set of descriptors.
See also the major sections below on _F_i_l_e _S_y_s_t_e_m_s and
_I_P_C.