jsq@ut-sally.UUCP (08/14/83)
- 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).