Unknown | 287 lines | 287 code | 0 blank | 0 comment | 0 complexity | d2a06d0c50142f9c78e7cae270732404 MD5 | raw file
1.\" Copyright (c) 1985 The Regents of the University of California. 2.\" All rights reserved. 3.\" 4.\" Redistribution and use in source and binary forms, with or without 5.\" modification, are permitted provided that the following conditions 6.\" are met: 7.\" 1. Redistributions of source code must retain the above copyright 8.\" notice, this list of conditions and the following disclaimer. 9.\" 2. Redistributions in binary form must reproduce the above copyright 10.\" notice, this list of conditions and the following disclaimer in the 11.\" documentation and/or other materials provided with the distribution. 12.\" 3. All advertising materials mentioning features or use of this software 13.\" must display the following acknowledgement: 14.\" This product includes software developed by the University of 15.\" California, Berkeley and its contributors. 16.\" 4. Neither the name of the University nor the names of its contributors 17.\" may be used to endorse or promote products derived from this software 18.\" without specific prior written permission. 19.\" 20.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND 21.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 22.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 23.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE 24.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 25.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 26.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 27.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 28.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 29.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 30.\" SUCH DAMAGE. 31.\" 32.\" @(#)5.t 5.1 (Berkeley) 4/17/91 33.\" 34.\" $FreeBSD$ 35.\" 36.ds RH Functional Extensions 37.NH 38Functional Extensions 39.PP 40Some of the facilities introduced in 4.2BSD were not completely 41implemented. An important part of the effort that went into 424.3BSD was to clean up and unify both new and old facilities. 43.NH 2 44Kernel Extensions 45.PP 46A significant effort went into improving 47the networking part of the kernel. 48The work consisted of fixing bugs, 49tuning the algorithms, 50and revamping the lowest levels of the system 51to better handle heterogeneous network topologies. 52.NH 3 53Subnets, Broadcasts and Gateways 54.PP 55To allow sites to expand their network in an autonomous 56and orderly fashion, subnetworks have been introduced in 4.3BSD [GADS85]. 57This facility allows sites to subdivide their local Internet address 58space into multiple subnetwork address spaces that are visible 59only by hosts at that site. To off-site hosts machines on a site's 60subnetworks appear to reside on a single network. The routing daemon 61has been reworked to provide routing support in this type of 62environment. 63.PP 64The default Internet broadcast address is now specified with a host part 65of all one's, rather than all zero's. 66The broadcast address may be set at boot time on a per-interface basis. 67.NH 3 68Interface Addressing 69.PP 70The organization of network interfaces has been 71reworked to more cleanly support multiple 72network protocols. Network interfaces no longer 73contain a host's address on that network; instead 74each interface contains a pointer to a list of addresses 75assigned to that interface. This permits a single 76interface to support, for example, Internet protocols 77at the same time as XNS protocols. 78.PP 79The Address Resolution Protocol (ARP) support 80for 10 megabyte/second Ethernet\(dg 81.FS 82\(dg Ethernet is a trademark of Xerox. 83.FE 84has been made more flexible by allowing hosts to 85act as a ``clearing house'' for hosts that do 86not support ARP. In addition, system managers have 87more control over the contents of the ARP translation 88cache and may interactively interrogate and modify 89the cache's contents. 90.NH 3 91User Control of Network Buffering 92.PP 93Although the system allocates reasonable default amounts of buffering 94for most connections, certain operations such as file system dumps 95to remote machines benefit from significant increases in buffering [Walsh84]. 96The \fIsetsockopt\fP system call has been extended to allow such requests. 97In addition, \fIgetsockopt\fP and \fIsetsockopt\fP, 98are now interfaced to the protocol level allowing protocol-specific 99options to be manipulated by the user. 100.NH 3 101Number of File Descriptors 102.PP 103To allow full use of the many descriptor based services available, 104the previous hard limit of 30 open files per process has been relaxed. 105The changes entailed generalizing \fIselect\fP to handle arrays of 10632-bit words, removing the dependency on file descriptors from 107the page table entries, 108and limiting most of the linear scans of a process's file table. 109The default per-process descriptor limit was raised from 20 to 64, 110though there are no longer any hard upper limits on the number 111of file descriptors. 112.NH 3 113Kernel Limits 114.PP 115Many internal kernel configuration limits have been increased by suitable 116modifications to data structures. 117The limit on physical memory has been changed from 8 megabyte to 64 megabyte, 118and the limit of 15 mounted file systems has been changed to 255. 119The maximum file system size has been increased to 8 gigabyte, 120number of processes to 65536, 121and per process size to 64 megabyte of data and 64 megabyte of stack. 122Note that these are upper bounds, 123the default limits for these quantities are tuned for systems 124with 4-8 megabyte of physical memory. 125.NH 3 126Memory Management 127.PP 128The global clock page replacement algorithm used to have a single 129hand that was used both to mark and to reclaim memory. 130The first time that it encountered a page it would clear its reference bit. 131If the reference bit was still clear on its next pass across the page, 132it would reclaim the page. 133The use of a single hand does not work well with large physical 134memories as the time to complete a single revolution of the hand 135can take up to a minute or more. 136By the time the hand gets around to the marked pages, 137the information is usually no longer pertinent. 138During periods of sudden shortages, 139the page daemon will not be able to find any reclaimable pages until 140it has completed a full revolution. 141To alleviate this problem, 142the clock hand has been split into two separate hands. 143The front hand clears the reference bits, 144the back hand follows a constant number of pages behind 145reclaiming pages that still have cleared reference bits. 146While the code has been written to allow the distance between 147the hands to be varied, we have not found any algorithms 148suitable for determining how to dynamically adjust this distance. 149.PP 150The configuration of the virtual memory system used to require 151a significant understanding of its operation to do such 152simple tasks as increasing the maximum process size. 153This process has been significantly improved so that the most 154common configuration parameters, such as the virtual memory sizes, 155can be specified using a single option in the configuration file. 156Standard configurations support data and stack segments 157of 17, 33 and 64 megabytes. 158.NH 3 159Signals 160.PP 161The 4.2BSD signal implementation would push several words 162onto the normal run-time stack before switching to an 163alternate signal stack. 164The 4.3BSD implementation has been corrected so that 165the entire signal handler's state is now pushed onto the signal stack. 166Another limitation in the original signal implementation was 167that it used an undocumented system call to return from signals. 168Users could not write their own return from exceptions; 1694.3BSD formally specifies the \fIsigreturn\fP system call. 170.PP 171Many existing programs depend on interrupted system calls. 172The restartable system call semantics of 4.2BSD signals caused 173many of these programs to break. 174To simplify porting of programs from inferior versions of 175.UX 176the \fIsigvec\fP system call has been extended so that 177programmers may specify that system calls are not to be 178restarted after particular signals. 179.NH 3 180System Logging 181.PP 182A system logging facility has been added 183that sends kernel messages to the 184syslog daemon for logging in /usr/adm/messages and possibly for 185printing on the system console. 186The revised scheme for logging messages 187eliminates the time lag in updating the messages file, 188unifies the format of kernel messages, 189provides a finer granularity of control over the messages 190that get printed on the console, 191and eliminates the degradation in response during the printing of 192low-priority kernel messages. 193Recoverable system errors and common resource limitations are logged 194using this facility. 195Most system utilities such as init and login, 196have been modified to log errors to syslog 197rather than writing directly on the console. 198.NH 3 199Windows 200.PP 201The tty structure has been augmented to hold 202information about the size 203of an associated window or terminal. 204These sizes can be obtained by programs such as editors that want 205to know the size of the screen they are manipulating. 206When these sizes are changed, 207a new signal, SIGWINCH, is sent the current process group. 208The editors have been modified to catch this signal and reshape 209their view of the world, and the remote login program and server 210now cooperate to propagate window sizes and window size changes 211across a network. 212Other programs and libraries such as curses that need the width 213or height of the screen have been modified to use this facility as well. 214.NH 3 215Configuration of UNIBUS Devices 216.PP 217The UNIBUS configuration routines have been extended to allow auto-configuration 218of dedicated UNIBUS memory held by devices. 219The new routines simplify the configuration of memory-mapped devices 220and correct problems occurring on reset of the UNIBUS. 221.NH 3 222Disk Recovery from Errors 223.PP 224The MASSBUS disk driver's error recovery routines have been fixed to 225retry before correcting ECC errors, support ECC on bad-sector replacements, 226and correctly attempt retries after earlier 227corrective actions in the same transfer. 228The error messages are more accurate. 229.NH 2 230Functional Extensions to Libraries and Utilities 231.PP 232Most of the changes to the utilities and libraries have been to 233allow them to handle a more general set of problems, 234or to handle the same set of problems more quickly. 235.NH 3 236Name Server 237.PP 238In 4.2BSD the name resolution routines (\fIgethostbyname\fP, 239\fIgetservbyname\fP, 240etc.) were implemented by a set of database files maintained on the 241local machine. 242Inconsistencies or obsolescence in these files resulted in inaccessibility of 243hosts or services. 244In 4.3BSD these files may be replaced by a network name server that can 245insure a consistent view of the name space in a multimachine environment. 246This name server operates in accordance with Internet standards 247for service on the ARPANET [Mockapetris83]. 248.NH 3 249System Management 250.PP 251A new utility, \fIrdist\fP, 252has been provided to assist system managers in keeping 253all their machines up to date with a consistent set of sources and binaries. 254A master set of sources may reside on a single central machine, 255or be distributed at (known) locations throughout the environment. 256New versions of \fIgetty\fP, \fIinit\fP, and \fIlogin\fP 257merge the functions of several 258files into a single place, and allow more flexibility in the 259startup of processes such as window managers. 260.PP 261The new utility \fItimed\fP keeps the time on a group of cooperating machines 262(within a single LAN) synchronized to within 30 milliseconds. 263It does its corrections using a new system call that changes 264the rate of time advance without stopping or reversing the system clock. 265It normally selects one machine to act as a master. 266If the master dies or is partitioned, a new master is elected. 267Other machines may participate in a purely slave role. 268.NH 3 269Routing 270.PP 271Many bugs in the routing daemon have been fixed; 272it is considerably more robust, 273and now understands how to properly deal with 274subnets and point-to-point networks. 275Its operation has been made more efficient by tuning with the use 276of execution profiles, along with inline expansion of common operations 277using the kernel's \fIinline\fP optimizer. 278.NH 3 279Compilers 280.PP 281The symbolic debugger \fIdbx\fP has had many new features added, 282and all the known bugs fixed. In addition \fIdbx\fP 283has been extended to work with the Pascal compiler. 284The fortran compiler \fIf77\fP has had numerous bugs fixed. 285The C compiler has been modified so that it can, optionally, 286generate single precision floating point instructions when operating 287on single precision variables.