compare.F
jsq at ut-sally.UUCP
jsq at ut-sally.UUCP
Sun Aug 14 14:14:17 AEST 1983
- 22 -
System V binary licenses are available, and the
Berkeley distribution is also available on two RK07 disk
packs.
For those unfamiliar with VAXen, _I_n_s_t_a_l_l_i_n_g _a_n_d
_O_p_e_r_a_t_i_n_g _4._1_C _B_S_D contains sections on VAX hardware
terminology and disk formatting which have no counterparts
in _S_e_t_t_i_n_g _U_p _t_h_e _U_N_I_X _S_y_s_t_e_m (the System V installation
guide).
Both systems provide a disk formatter. The _f_o_r_m_a_t
command provided with System V will format RP06 and RM03/05
disks. The formatter of 4.1C and 4.2 formats almost any
non-DEC UNIBUS or MASSBUS drive, and also includes RM03s and
RM05s, i.e., any disk with the BSC bit in the header. It
cannot handle RP06, RP07, or UDA50s, but the DEC formatter
can do those.
We had no real problems booting either system. (The
System III boot bugs seem to be fixed in System V.)
3.2 Configuration
Both systems are relatively easy to configure.
System V includes driver support for most devices of
interest, including the RM05, RM80, and RP04/5/6/7 disks.
4.1C BSD supports all of the devices just mentioned,
plus many others, and also understands the full
interconnection architecture of the VAX, so that it is
possible to have, say, two RP06's on one MASSBUS and another
on a second, and the system may be permitted to decide at
configuration time which MASSBUS's the RP06's are on.
System V is configured by running the _c_o_n_f_i_g program
against a system description file; entries in the file are
checked against a list of supported devices in /etc/master.
The _v_c_f command may then be used in standalone mode to
verify address and interrupt information in the kernel
object against the actual hardware present on the system.
4.1C and 4.2 are configured with a _c_o_n_f_i_g program too,
but this one works markedly differently. The sources are
arranged in such a way that several different kernels (for
the same or different machines) can easily be made from the
same sources. Things such as network node names are
parameterized at run time so that the same kernel can easily
run on several machines with the same CPU and peripherals.
If desired, a generic kernel (such as on the distribution
tape) can be configured that will find likely devices at
- 23 -
startup.
System V still requires hand-setting of numerous
parameters, such as the number of process, file, and inode
table slots, while 4BSD (4.1 and later) decides appropriate
values for these parameters on the basis of one number: the
number of users the machine is to support. (The default
rules can be overridden, of course.)
3.3 Transition
The transition from 4.1BSD to 4.1C BSD (or 4.2) should
not be very troublesome. Though the file system
implementation is quite different, the user interface is
almost identical, especially since system calls that have
been replaced are simulated. The long file names are, of
course, not a problem. The new directory format might
appear to be, but there should be few programs other than
system ones (which are supplied) that read directories
directly.
Directions for the transition are given in
_I_n_s_t_a_l_l_i_n_g/_O_p_e_r_a_t_i_n_g _4._2_b_s_d under the section ``Upgrading a
4BSD System,'' and _A _4._1_a _U_s_e_r'_s _G_u_i_d_e _t_o _4._1_c provides
useful user orientation.
There are no provisions for upgrading from a system
previous to 4BSD, such as 3.0 or 32V, though this could
presumably be done with sufficient investment of effort.
System V is distributed with a document, _T_r_a_n_s_i_t_i_o_n
_A_i_d_s, designed to assist the system administrator in
changing from System III to System V.
Especially crucial transition topics include: hardware
support changes (esp. lack of DH-11 support); whether to
convert to a 1K file system; conversion to the new archive
format; and conversion of objects or (preferably)
recompilation of sources for user programs to accomodate the
new headers and object file format.
4. Sources and Documentation
There has been a large amount of reorganization of
sources, documentation, and associated support since 32V.
- 24 -
4.1 Make
System V includes the extended _m_a_k_e, which features
many additional default rules to handle common conditions,
to the point that many compilations require no makefile.
Additions are also present which handle archives and SCCS
files (see below) and make use of environment variables and
defaults. Most system programs may be rebuilt by using the
collection of :mk command files located in the source tree.
The 4.1C BSD _m_a_k_e seems to be very much in the flavor
of V.7. Rebuilding the whole source tree is as easy as in
System V, however, and is recommended to be done frequently.
4.2 SCCS
System V includes the PWB Source Code Control System
(SCCS), not available in 4.1C BSD. 4.2 is rumored to
include RCS, a public-domain rendering of SCCS.
4.3 Sources
System V preserves the changes to the names of source
directories and files which System III introduced (the
kernel ``sys'' subdirectory becomes ``os'', and ``dev''
becomes ``io''). However, since there is an appropriate
makefile (or :mk command file) for almost everything it is
possible to go to the appropriate parent directory for a
software package and let _m_a_k_e do the work.
The 4.1C sources, both user and kernel, have been
radically reorganized in order to simplify recompilation of
the entire system and to promote portability. There is
generally a source directory subtree corresponding to each
directory containing objects, e.g., /usr/src/usr.bin for
/usr/bin, making sources easy to locate. Good use has been
made of symbolic links, in order to avoid duplication of
sources, and to allow keeping certain pieces (such as the
kernel sources) on whatever file system is appropriate,
e.g., /usr/include/sys is a symbolic link to /sys/h, and
/sys is itself a symbolic link to /usr/sys.
The kernel sources have all the VAX-specific code
separated out into different directories and files from the
portable code. The user sources have also been similarly
organized for portability. The C library, in particular,
has been redone. One would expect 4.1C to be as portable to
another 32-bit machine as 32V or System V.
There is a rather widespread problem in Berkeley code
consisting of the use of the type int when long, or even
- 25 -
off_t, or especially time_t is meant. This works fine, as
long as you never try to run such code on a machine where
int is smaller than 32 bits. (This problem is not evident
in the kernel, but rather, in application programs.) This
problem is perhaps less prevalent in 4.1C than in 4.1.
Fairness requires mentioning that there are also
numerous places in the documentation where it is asserted
that int is 32 bits, on the grounds that machines with
smaller word sizes are not sufficient for many of the
functions 4BSD supports.
4.4 Documentation
Berkeley provides the traditional _U_n_i_x _P_r_o_g_r_a_m_m_e_r'_s
_M_a_n_u_a_l, volumes I, IIA, and IIB, plus an additional volume
of papers written at Berkeley and related directly to the
Berkeley parts of the system. The documents come as
duplication quality masters of 8-1/2 by 11 inch pages
suitable for ordinary three-ring looseleaf binders. The
first volume has of course been updated and is also kept
on-line for easy access.
System V has largely reorganized the system
documentation. Volume one has been divided into a _U_s_e_r'_s
_M_a_n_u_a_l, an _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _M_a_n_u_a_l, and, peripherally, the
_O_p_e_r_a_t_i_n_g _S_y_s_t_e_m _E_r_r_o_r _M_e_s_s_a_g_e _M_a_n_u_a_l. Most of the classic
UNIX papers which appear in volume two in the Berkeley
distribution have been pieced together to form such things
as a _D_o_c_u_m_e_n_t _P_r_o_c_e_s_s_i_n_g _G_u_i_d_e and a _P_r_o_g_r_a_m_m_i_n_g _G_u_i_d_e. All
in all, there are twelve documents furnished with the
purchase of a System V license; extra copies are for sale by
Western Electric Software Sales and Marketing.
It is disappointing to note that not all of the
documentation is provided on the distribution tape, a
feature considered critical by some (e.g. the sight-
impaired).
5. Groups and Identifiers
4.1C changes the implementation of groups and related
identifiers sufficiently to motivate this section.
5.1 Groups
System V uses the old V7/32V group scheme: a user may
have access to a login group (specified in /etc/passwd) and
also to several other groups (as permitted by /etc/group),
but may be in only one group at a time.
- 26 -
In 4.1C, the same files in the same formats determine
what groups a user is allowed in, but the user is
immediately put in _a_l_l of them at login: there is no _n_e_w_g_r_p
command. The _g_r_o_u_p_s command lists the groups you are in.
The maximum number of simultaneous groups is a system
compile-time parameter, and the default is eight. The
_s_e_t_g_r_o_u_p_s system call can be used (by superuser) to set the
groups for a process.
In both systems, each file has a single group
associated with it to determine group read, write, execute,
and setgid permissions. System V creates a new file in the
effective group of the process, whereas 4.1C creates the
file in the group of its parent directory.
Both systems have _c_h_g_r_p (both command and system call)
to change the group of an existing file. 4.1C allows the
user to change the group of a file he owns to be any of the
groups to which he belongs. System V allows the user to
change the user and group id of any file he owns, thus
giving the file away. 4BSD does not, apparently because of
the existence of disk space quotas, which System V lacks.
5.2 Identifiers
Berkeley has extended the setuid and setgid system
calls in 4.1C to allow setting the effective id to the value
of the real id, as well as the reverse. This is very useful
for things like network server daemons, which may now switch
permissions between superuser privileges and those of an
ordinary user, and back, in a single process. This (along
with the socket IPC and non-blocking I/O) allows many
daemons to be implemented as one process where formerly two
were required.
Group ids and process ids are 32 bit integer quantities
in 4.1C. The high order 16 bits of the process id are not
yet used, but probably will be with the development of
distributed applications.
6. File Systems
Both systems have file systems different from their
predecessors and each other. Though the comments in this
section may make the differences seem extreme, the user
interface is not much changed in either case from 32V, and
we have had no trouble transferring files between the two
systems with either _t_a_r or _c_p_i_o (though _c_p_i_o had to be
ported to 4.1C first, of course).
More information about the Comp.sources.unix
mailing list