|
|
Line 21: |
Line 21: |
| This version seems to have been released on June 6th 1986. (dated from the GENERIC build directory in the kernel source tree.) | | This version seems to have been released on June 6th 1986. (dated from the GENERIC build directory in the kernel source tree.) |
| | | |
− |
| |
− | == 4.3 BSD-Reno ==
| |
− |
| |
− | Following up in 1990 comes -Reno, with a significant thrust toward POSIX compliance, (with an associated increase in code size).
| |
− |
| |
− | === Announcement ===
| |
− | http://groups.google.com/group/comp.archives/browse_thread/thread/75ef2eac9c5baf24?q=V1.90+4.3BSD
| |
− | <pre>
| |
− | Newsgroups: comp.archives
| |
− | Followup-To: comp.bugs.4bsd.ucb-fixes
| |
− | From: bos...@OKEEFFE.BERKELEY.EDU (Keith Bostic)
| |
− | Date: 6 Jul 90 16:11:59 GMT
| |
− | Local: Fri, Jul 6 1990 11:11 am
| |
− | Subject: [comp.bugs.4bsd.ucb-fixes] V1.90 (4.3BSD-Reno)
| |
− | Archive-name: 4.3bsd-reno/06-Jul-90
| |
− | Original-posting-by: bos...@OKEEFFE.BERKELEY.EDU (Keith Bostic)
| |
− | Original-subject: V1.90 (4.3BSD-Reno)
| |
− | Reposted-by: e...@math.lsa.umich.edu (Edward Vielmetti)
| |
− |
| |
− | Subject: 4.3BSD-Reno
| |
− |
| |
− |
| |
− | Description:
| |
− | 4.3BSD-Reno is available! The attached is the cover letter
| |
− | of the information packet which will be sent to 4BSD licensees
| |
− | in the next few days.
| |
− |
| |
− |
| |
− | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| |
− |
| |
− |
| |
− | Dear Colleague:
| |
− |
| |
− |
| |
− | We are happy to send you information about our June, 1990
| |
− | test release of the Fourth Berkeley Software Distribution,
| |
− | 4.3BSD-Reno. This release represents an intermediate point in
| |
− | the development of 4.4BSD; several new facilities have been com-
| |
− | pleted and are ready for external use, while other new facilities
| |
− | slated for the 4.4BSD release have not yet been integrated. Our
| |
− | goal in making this release available is to get feedback on any
| |
− | problems in the design or implementation of the new facilities,
| |
− | as well as to allow adventurous sites to gain experience with
| |
− | these portions of 4.4BSD.
| |
− |
| |
− |
| |
− | This distribution is NOT intended to be used on production
| |
− | systems; nor is it intended for sites without sufficient local
| |
− | expertise to find and fix any problems that are encountered. It
| |
− | is intended to be used to provide an advance look at some of the
| |
− | facilities and interfaces that we will be distributing in 4.4BSD.
| |
− | We are interested in getting feedback on the problems that you
| |
− | find and also any compatibility problems that you anticipate in
| |
− | trying to convert your applications to run on this release. The
| |
− | interfaces in this release will change before the release of
| |
− | 4.4BSD (at least in part based on feedback from this test group).
| |
− | Thus, you should not expect applications ported to this release
| |
− | to work unchanged on 4.4BSD.
| |
− |
| |
− |
| |
− | Unlike past test releases, 4.3BSD-Reno is being made gen-
| |
− | erally available to 4.3BSD licensees, and 4.3BSD-Reno may be
| |
− | redistributed and used in released products (within the usual
| |
− | licensing constraints). However, you will have to upgrade any
| |
− | code that you use from 4.3BSD-Reno to the 4.4BSD code within one
| |
− | year of the release of 4.4BSD. We appreciate your help in this
| |
− | debugging effort and look forward to hearing from you. Please
| |
− | send your comments to reno43-b...@okeeffe.Berkeley.EDU. We
| |
− | regret that changes documents are not available; the next section
| |
− | outlines the major changes available in 4.3BSD-Reno.
| |
− |
| |
− |
| |
− | The license to 4.3BSD-Reno is simply an Addendum to the
| |
− | 4.3BSD License. Sites without a 4.3BSD license may obtain both
| |
− | 4.3BSD and 4.3BSD-Reno simultaneously, but must sign a 4.3BSD
| |
− | license as well as the Addendum. Contact the distribution office
| |
− | for 4.3BSD licensing information. 4.3BSD is available only to
| |
− | sites with UNIX/32V, System III, or System V source licenses
| |
− | with AT&T. We are actively working to decrease the amount of
| |
− | AT&T code in the system. We expect that we will provide a subset
| |
− | of 4.4BSD without the AT&T code to sites without requiring an
| |
− | AT&T license. However, we are not prepared to make that determi-
| |
− | nation for this release, so we are providing only tapes with the
| |
− | complete system at this time.
| |
− |
| |
− |
| |
− | The enclosed information is designed to serve two purposes.
| |
− | The first purpose is to acquaint you with the details of our dis-
| |
− | tribution so you can decide whether you would like to receive it.
| |
− | The second purpose is to tell you how to obtain our distribution.
| |
− |
| |
− |
| |
− | What is 4.3BSD-Reno?
| |
− |
| |
− |
| |
− | The distribution consists of one 6250 bpi or three 1600 bpi
| |
− | magnetic tapes containing full sources and documentation plus one
| |
− | set of binaries. You may specify VAX and/or Tahoe (CCI Power
| |
− | 6/32) binaries.
| |
− |
| |
− |
| |
− | The three major new facilities available in the 4.3BSD-Reno
| |
− | release are the addition of ISO/OSI networking support, a freely
| |
− | redistributable implementation of NFS, and the conversion to and
| |
− | addition of the POSIX.1 facilities. There are numerous other
| |
− | changes throughout the system.
| |
− |
| |
− |
| |
− | The ISO/OSI Networking consists of a kernel implementation
| |
− | of transport class 4 (TP-4), connectionless networking protocol
| |
− | (CLNP), and 802.3-based link-level support (hardware-compatible
| |
− | with Ethernet*). The session and presentation layers will be
| |
− | provided outside the kernel by the ISO development environment
| |
− | (ISODE). Included in this development environment are file
| |
− | transfer and management (FTAM), virtual terminals (VT), a direc-
| |
− | tory services implementation (X.500), and miscellaneous other
| |
− | utilities.
| |
− |
| |
− |
| |
− | A new virtual filesystem interface has been added to the
| |
− | kernel to support multiple filesystems. Although generally simi-
| |
− | lar to Sun's vnode interface, the Berkeley interface has been
| |
− | structured for more efficient support of filesystems that main-
| |
− | tain state (such as the local filesystem). In addition to the
| |
− | local ``fast filesystem'', we have added an implementation of the
| |
− | network filesystem (NFS) that fully interoperates with the NFS
| |
− | shipped by Sun and its licensees. Because our NFS implementation
| |
− | was implemented using only the publicly available NFS
| |
− | specification, it does not require a license from Sun to use in
| |
− | source or binary form. By default it runs over UDP to be compa-
| |
− | tible with Sun's implementation. However, it can be configured
| |
− | on a per-mount basis to run over TCP. Using TCP allows it to be
| |
− | used quickly and efficiently through gateways and over long-haul
| |
− | networks. We have also added a memory-based filesystem that runs
| |
− | in pageable memory, which allows large temporary filesystems
| |
− | without requiring dedicated physical memory.
| |
− |
| |
− |
| |
− | The quota system has been rewritten to support both user and
| |
− | group quotas (simultaneously if desired). Quota expiration is
| |
− | based on time rather than the previous metric of number of logins
| |
− | over quota. This change makes quotas more useful on fileservers
| |
− | onto which users seldom login.
| |
− |
| |
− |
| |
− | The 4.3BSD-Reno distribution contains most of the interfaces
| |
− | specified in the POSIX.1 system interface standard. The biggest
| |
− | area of change is a new terminal driver. The terminal driver is
| |
− | similar to the System V terminal driver with the addition of the
| |
− | necessary extensions to get the functionality previously avail-
| |
− | able in the 4.3BSD terminal driver. 4.3BSD-Reno also adds the
| |
− | POSIX job control interface, which is similar to the 4.3BSD job
| |
− | control interface, but adds a security model that was missing in
| |
− | the 4.3BSD job control implementation. Other additions include
| |
− | POSIX signals, FIFO's, and saved user and group identifiers. We
| |
− | have been tracking the POSIX shell and utility work and have
| |
− | included prototypes of many of the proposed utilities. Finally,
| |
− | we have converted about 80% of the libraries and header files to
| |
− | be compliant with ANSI C.
| |
− |
| |
− |
| |
− | Work has also progressed in several other areas. Several
| |
− | important enhancements have been added to the TCP/IP protocols
| |
− | including TCP header prediction and serial line IP (SLIP) with
| |
− | header compression. The routing implementation has been com-
| |
− | pletely rewritten to use a hierarchical routing tree with a mask
| |
− | per route to support the arbitrary levels of routing found in the
| |
− | ISO protocols. The routing table also stores and caches route
| |
− | characteristics to speed the adaptation of the throughput and
| |
− | congestion avoidance algorithms.
| |
− |
| |
− |
| |
− | The Kerberos (version 4) authentication software has been
| |
− | integrated into much of the system (except NFS) to provide the
| |
− | first real network authentication on BSD.
| |
− |
| |
− |
| |
− | The hardware supported by 4.3BSD-Reno is:
| |
− |
| |
− |
| |
− | + VAX (86x0, 78x, 750, 730; MicroVAX II, 3200/3500/3600; 82x0)
| |
− |
| |
− |
| |
− | + Tahoe (CCI Power 6/32, 6/32SX; Unisys 7000/xx; Harris HCX7,
| |
− | HCX9)
| |
− |
| |
− |
| |
− | + HP 9000/300 series
| |
− |
| |
− |
| |
− | In addition, kernel support for the Intel i386 and many AT-bus
| |
− | peripherals has been added recently; contact the distribution
| |
− | office for a list of supported hardware if necessary.
| |
− |
| |
− |
| |
− | For this distribution, binaries will be available for only the
| |
− | VAX and Tahoe architectures. The 4.4BSD distribution will prob-
| |
− | ably be available for all the above architectures as well as
| |
− | several machines based on the MIPS processor.
| |
− |
| |
− |
| |
− | The reason that this distribution is not labeled 4.4BSD-
| |
− | alpha is because it does not contain several major interfaces
| |
− | that we plan to have available for that distribution. These
| |
− | include:
| |
− |
| |
− |
| |
− | + A new virtual memory system using the mmap interface
| |
− | described in the 4.3BSD architecture document. The inter-
| |
− | face is similar to the interface shipped in several commer-
| |
− | cial versions of UNIX such as SunOS 4.0.
| |
− |
| |
− |
| |
− | + Support for ISO Connection-Oriented Network Service, X.25,
| |
− | TP-0.
| |
− |
| |
− |
| |
− | + A new internal network layering (``bstreams'') combining
| |
− | features of the current socket layering and of Streams.
| |
− |
| |
− |
| |
− | + Fixes, tuning, fixes, documentation, and fixes.
| |
− |
| |
− |
| |
− | This release does include several important structural ker-
| |
− | nel changes. The most pervasive change is to eliminate the user
| |
− | structure fields u.u_error, u.u_u_r.r_val1, and u.u_ap by using a
| |
− | new internal system call convention:
| |
− | error = (*callp)(proc, args, retval);
| |
− |
| |
− |
| |
− | We are also reducing the use of other global variables with the
| |
− | intent to eventually eliminate all references to the user area
| |
− | except for the per-process runtime stack. Thus, all substruc-
| |
− | tures will eventually be referenced via the proc structure.
| |
− |
| |
− |
| |
− | Another major change is the introduction of a new sleep
| |
− | interface:
| |
− | error = tsleep(wchan, pri|PCATCH, wstring, timeout);
| |
− |
| |
− |
| |
− | The old sleep interface can be used only for non-interruptible
| |
− | sleeps. The tsleep interface can be used at any priority, but is
| |
− | only interruptible if the PCATCH flag is set. When interrupted,
| |
− | tsleep returns EINTR or ERESTART; all non-local goto's
| |
− | (longjmp's) have been eliminated from the kernel.
| |
− |
| |
− |
| |
− | Many data structures that were previously statically allo-
| |
− | cated are now allocated dynamically. These structures include
| |
− | the mount table, the vnode table, the name cache, and the quota
| |
− | structures.
| |
− |
| |
− |
| |
− | How to obtain the 4.3BSD-Reno release
| |
− |
| |
− |
| |
− | All previous 4.3BSD licensees will be able to receive the
| |
− | 4.3BSD Reno release simply by executing the steps outlined below.
| |
− | 4.2BSD licensees who have not yet upgraded to 4.3BSD will be
| |
− | required to do so as well as following the steps outlined below
| |
− | for the Reno distribution. For further information on ordering
| |
− | the standard 4.3BSD distribution, contact our distribution office
| |
− | at the address given below.
| |
− |
| |
− |
| |
− | Because we are a research and development organization and
| |
− | not a commercial organization, we make our research results
| |
− | available for a fee which covers only our costs for the distribu-
| |
− | tion. We distribute only the whole system and cannot send indi-
| |
− | vidual pieces of the system. Because the software is distributed
| |
− | ``As Is'' and is partially derived from licensed material, we are
| |
− | required to have a formal license arrangement with each organiza-
| |
− | tion to which we distribute.
| |
− |
| |
− |
| |
− | Specifically, we must receive from your organization the
| |
− | following material before the distribution can be sent:
| |
− |
| |
− |
| |
− | + Two appropriate signed Addenda for the Reno distribution if
| |
− | you are a 4.3BSD licensee. Add to that the appropriate
| |
− | Addendum to receive the upgrade if you are a 4.2BSD licen-
| |
− | see. For new licensees, two executed copies of the Berkeley
| |
− | License Agreement (4/86) with the appropriate Addendum,
| |
− | i.e., for foreign or US government sites, plus the Addendum
| |
− | for the Reno distribution. We require two copies of all
| |
− | Agreements/Addenda with original signatures, one of which is
| |
− | returned to the Licensee. The name of the organization on
| |
− | the Addendum No. Three must be the same as that which
| |
− | appears on the Software Agreement with AT&T (or Western
| |
− | Electric). The Addendum No. Three must be signed by a duly
| |
− | authorized person who holds a position that is at the same
| |
− | level or a higher level of authority as that which appears
| |
− | on the AT&T Software Agreement. Please have this person's
| |
− | name and title typed in the available space in addition to
| |
− | the signature.
| |
− |
| |
− |
| |
− | + A check from a U.S. bank for $495.00 U.S. (for a single 6250
| |
− | BPI tape of 4.3BSD-Reno) or $595.00 (for three 1600 BPI
| |
− | tapes of 4.3BSD-Reno) payable to ``The Regents of the
| |
− | University of California'' must be received before the dis-
| |
− | tribution can be sent. If you must issue a Purchase Order,
| |
− | please issue one that is blank-backed. If this is not pos-
| |
− | sible, insert and initialize in the body of the Purchase
| |
− | Order the following clause: ``The terms and conditions of
| |
− | this Purchase Order are not accepted by The Regents of the
| |
− | University of California. The revised Berkeley License
| |
− | Agreement (4/86) governs.'' For 4.2 licensees that have
| |
− | updated to 4.3BSD, substitute ``The terms and conditions of
| |
− | this Purchase Order are not accepted by The Regents of the
| |
− | University of California. The revised Berkeley License
| |
− | Agreement (6/83) and Addendum Number Three govern.''
| |
− |
| |
− |
| |
− | + A completed Site Information Form. The distribution itself
| |
− | will be sent to the technical contact. The site information
| |
− | is kept confidential and is for our use in identifying sites
| |
− | with specific configurations. Please note that we cannot
| |
− | ship to post office boxes; therefore, please have the techn-
| |
− | ical contact's address supplied without use of a post office
| |
− | box.
| |
− |
| |
− |
| |
− | A checklist is included to aid you in assembling this
| |
− | material. All the above material must be sent to:
| |
− |
| |
− |
| |
− | Distribution Coordinator
| |
− | Computer Systems Research Group
| |
− | Computer Science Division, EECS
| |
− | University of California
| |
− | Berkeley, California 94720
| |
− |
| |
− |
| |
− | Once all these items have been received and are in proper order,
| |
− | the distribution will be sent to the technical address indicated
| |
− | on the Site Information Form that you provided when you placed
| |
− | your order; we cannot provide delivery dates. Once the material
| |
− | is assembled and packaged, the distribution is shipped by commer-
| |
− | cial carrier. Order of shipment will be based on time of arrival
| |
− | of the properly completed paperwork. Because of the differential
| |
− | in costs of shipping outside the United States, we ask that
| |
− | organizations beyond the North American continent pay the collect
| |
− | shipping charges.
| |
− |
| |
− |
| |
− | The most expedient way to insure that your full distribution
| |
− | is sent as quickly as possible is to include in a single package
| |
− | the signed appropriate Addenda (without modification) for the
| |
− | Reno distribution plus any other necessary signed legal papers,
| |
− | depending on your licensing status, the appropriate check prop-
| |
− | erly made out to ``The Regents of the University of California,''
| |
− | and a completely filled-out Site Information Form, and to send
| |
− | this single package to the address noted above.
| |
− |
| |
− |
| |
− | Large Organizations
| |
− |
| |
− |
| |
− | Many large organizations have multiple entities that act
| |
− | independently from one another and are licensed independently
| |
− | from AT&T. Others have the parent organization licensed by AT&T
| |
− | and copies of the software distribution sent to each independent
| |
− | entity. The Berkeley License Agreement must be executed with the
| |
− | organization holding the appropriate AT&T Software Agreement.
| |
− |
| |
− |
| |
− | If your organization has an AT&T license and chooses not to
| |
− | redistribute internally, please contact us for a copy of the
| |
− | letter of authorization to be executed by the parent company.
| |
− |
| |
− |
| |
− | Special Cases
| |
− |
| |
− |
| |
− | University of California Sites. If you are a part of the
| |
− | University of California, and do not already have an AT&T source
| |
− | license for your CPU, you must use the following procedure: ask
| |
− | Pam True (415) 642-6348 at Berkeley Campus Materiel Management
| |
− | for an application for an additional CPU authorization under The
| |
− | Regents of the University of California's Software Agreement with
| |
− | AT&T. We will receive the completed application from Materiel
| |
− | Management. If you have previously obtained a Berkeley License
| |
− | for your CPU or have an AT&T source license for your CPU, you do
| |
− | not need to contact the Materiel Management Office.
| |
− |
| |
− |
| |
− | In all cases, the following items must be sent to the Com-
| |
− | puter Systems Research Group: 1) a letter signed by the Director
| |
− | or Head of Department requesting 4.3BSD-Reno, stating that you
| |
− | have read and understood the Berkeley License Agreement and that
| |
− | your organization will abide by it, 2) an IOC for $495.00 or
| |
− | $595.00 (1600 BPI), and 3) a Site Information Form if the contact
| |
− | information has changed.
| |
− |
| |
− |
| |
− | DARPA Sites. The research on which the Berkeley Software
| |
− | Distributions are based has been sponsored by DARPA (Defense
| |
− | Advanced Research Projects Agency). Provision has been made for
| |
− | prepayment of distribution costs for a few designated DARPA
| |
− | sites. In place of the check for $495.00 or $595.00, you should
| |
− | include a letter from your Program Manager stating that you are
| |
− | designated as such a site. However, you must comply with all
| |
− | other requirements in applying for the distribution.
| |
− |
| |
− |
| |
− | A Special Note
| |
− |
| |
− |
| |
− | The procedures and rules set out in this document are
| |
− | University and AT&T constraints that must be followed in order
| |
− | for the distribution of software to be possible. The Computer
| |
− | Systems Research Group has no control over these constraints and
| |
− | must reject your application if material submitted is not in
| |
− | order.
| |
− |
| |
− |
| |
− | If You Have Read Everything and Still Need Help
| |
− |
| |
− |
| |
− | If you have questions about the licensing process after
| |
− | reading this letter, you may call the distribution group at (415)
| |
− | 642-7780, write to them at the address above, or contact them via
| |
− | electronic mail at bsd-d...@Berkeley.EDU or ucbvax!bsd-dist. They
| |
− | will not be able to answer technical questions.
| |
− |
| |
− |
| |
− | Sincerely yours,
| |
− |
| |
− |
| |
− | Mike Karels
| |
− | Computer Systems Research Group
| |
− | July 6, 1990
| |
− |
| |
− |
| |
− | _________________________
| |
− | UNIX, UNIX/32V, UNIX System III, and UNIX System V are registered
| |
− | trademarks of AT&T in the USA and other countries.
| |
− | Ethernet is a trademark of the Xerox Corporation.
| |
− | </pre>
| |
| | | |
| == 4.3 BSD-Quasijarus == | | == 4.3 BSD-Quasijarus == |
Line 482: |
Line 39: |
| *Installation instructions for 4.3 BSD can be found [[Installing 4.3 BSD on SIMH|here]] | | *Installation instructions for 4.3 BSD can be found [[Installing 4.3 BSD on SIMH|here]] |
| *Installation instructions for 4.3 BSD TAHOE can be found [[Installing 4.3 BSD TAHOE on SIMH|here]] | | *Installation instructions for 4.3 BSD TAHOE can be found [[Installing 4.3 BSD TAHOE on SIMH|here]] |
− | *Installation instructions for 4.3 BSD RENO can be found [[Installing 4.3 BSD RENO on SIMH|here]]
| |
| *Installation instructions for 4.3 BSD Quasijarus 0c can be found [[Installing_4.3_BSD_Quasijarus_on_SIMH|here]] | | *Installation instructions for 4.3 BSD Quasijarus 0c can be found [[Installing_4.3_BSD_Quasijarus_on_SIMH|here]] |
| | | |
| == What Runs? == | | == What Runs? == |
| | | |
− | 4.3 BSD-Reno includes a large amount of POSIX which dramatically improves compatibility with many modern and older *nix packages. A lot of people don't like -Reno as its embracing of POSIX is rather treasonous to the BSD ideal. So what compiles on 4.3 BSD-Tahoe or its maintained version, -Quasijarus?
| + | A lot of people don't like -Reno as its embracing of POSIX is rather treasonous to the BSD ideal. So what compiles on 4.3 BSD-Tahoe or its maintained version, -Quasijarus? |
| | | |
| === Quasijarus === | | === Quasijarus === |