diff --git a/handbook/contrib.sgml b/handbook/contrib.sgml index 2d16530f6f..8ddbd8d090 100644 --- a/handbook/contrib.sgml +++ b/handbook/contrib.sgml @@ -1,407 +1,407 @@ - + FreeBSD contributor list Derived software contributors

This software was originally derived from William F. Jolitz's 386BSD release 0.1, though almost none of the original 386BSD specific code remains. This software has - been essentially re-implemented from the 4.4 BSD Lite + been essentially re-implemented from the 4.4BSD-Lite release provided by the Computer Science Research Group (CSRG) at the University of California, Berkeley and associated academic contributors. There are also portions of NetBSD that have been integrated into FreeBSD as well, and we would therefore like to thank all the contributors to NetBSD for their work. Despite some occasionally rocky moments in relations between the two groups, we both want essentially the same thing: More BSD based operating systems on people's computers! We wish the NetBSD group every success in their endeavors. Hardware contributors

A special thank-you to Walnut Creek CDROM for providing the Pentium P5-90 and 486/DX2-66 EISA/VL systems that are being used for our development work, to say nothing of the network access and other donations of hardware resources. It would have been impossible to do this release without their support. TRW Financial Systems, Inc. provided 130 PCs, three 68 GB fileservers, twelve Ethernets, two routers and an ATM switch for debugging the diskless code. They also keep a couple of FreeBSD hackers alive and busy. Thanks! Thanks also to Dermot McDonnell for his donation of a Toshiba XM3401B CDROM drive. It has been most useful! Thanks to Chuck Robey <chuckr@eng.umd.edu> who contributed his floppy tape streamer for experimental work. Thanks to Larry Altneu <larry@ALR.COM>, and to Wilko Bulte <wilko@yedi.iaf.nl>, for providing us with a Wangtek and an Archive QIC-02 tape drive, in order to give us the hardware to improve the wt driver. Thanks go to Ernst Winter <ewinter@lobo.muc.de>, for contributing a 2.88 MB floppy drive to the project. Hopefully, this will increase the pressure for rewriting the floppy disk driver. ;-) Also see for a list of people who have donated funding or services to the FreeBSD Project. The FreeBSD core team

(in alphabetical order by last name): &a.asami &a.ache &a.dyson &a.bde &a.gibbs &a.davidg &a.jkh &a.phk &a.rich &a.gpalmer &a.sos &a.peter &a.wollman &a.joerg The FreeBSD Developers

These are the people who have commit privileges and do the work on the FreeBSD source tree. All core team members are also developers. &a.torstenb; &a.gclarkii; &a.adam; &a.dufault; &a.uhclem; &a.julian; &a.sef; &a.se; &a.fenner; &a.jfieber; &a.jfitz; &a.scrappy; &a.jhay; &a.lars; &a.tg; &a.graichen; &a.rgrimes; &a.hsu; &a.ugen; &a.gj; &a.andreas; &a.ljo; &a.erich; &a.smace; &a.amurai; &a.markm; &a.alex; &a.wpaul; &a.smpatel; &a.jmacd; &a.jdp; &a.mpp; &a.dfr; &a.csgr; &a.martin; &a.paul; &a.roberto; &a.jraynard; &a.chuckr; &a.dima; &a.wosch; &a.ats; &a.karl; &a.pst; &a.guido; &a.swallace; &a.nate; &a.jmz; Who is responsible for what

Additional FreeBSD contributors

(in alphabetical order by first name): A JOSEPH KOSHY <koshy@india.hp.com> ABURAYA Ryushirou <pcs51674@asciinet.or.jp> Adam Glass <glass@postgres.berkeley.edu> Adrian T. Filipi-Martin <atf3r@agate.cs.virginia.edu> Akito Fujita <fujita@zoo.ncl.omron.co.jp> Alain Kalker <A.C.P.M.Kalker@student.utwente.nl> Alex Nash <nash@mcs.com> Andy Whitcroft <andy@sarc.city.ac.uk> Andreas Klemm <andreas@knobel.GUN.de> Andrew Gordon <andrew.gordon@net-tel.co.uk> Andrew Herbert <andrew@werple.apana.org.au> Andreas Kohout <shanee@rabbit.augusta.de> Andrew McRae <amcrae@cisco.com> Andrew Moore <alm@FreeBSD.org> Andrew V. Stesin <stesin@elvisti.kiev.ua> Andrey Zakhvatov <andy@cgu.chel.su> Anthony Yee-Hang Chan <yeehang@netcom.com> Bernd Rosauer <br@netland.inka.de> Bob Wilcox <bob@obiwan.uucp> Brent J. Nordquist <nordquist@platinum.com> Brian Clapper <bmc@telebase.com> Brian Tao <taob@io.org> Charles Hannum <mycroft@ai.mit.edu> Chet Ramey <chet@odin.INS.CWRU.Edu> Chris G. Demetriou <cgd@postgres.berkeley.edu> Chris Stenton <jacs@gnome.co.uk> Chris Timmons <skynyrd@opus.cts.cwu.edu> Chris Torek <torek@ee.lbl.gov> Christian Gusenbauer <cg@fimp01.fim.uni-linz.ac.at> Christian Haury <Christian.Haury@sagem.fr> Christoph Robitschko <chmr@edvz.tu-graz.ac.at> Chuck Hein <chein@cisco.com> Cornelis van der Laan <nils@guru.ims.uni-stuttgart.de> Craig Struble <cstruble@vt.edu> Cristian Ferretti <cfs@riemann.mat.puc.cl> Curt Mayer <curt@toad.com> Daniel Baker <dbaker@crash.ops.neosoft.com> Daniel M. Eischen <deischen@iworks.InterWorks.org> Danny J. Zerkel <dzerkel@feephi.phofarm.com> Dave Bodenstab <imdave@synet.net> Dave Burgess <burgess@hrd769.brooks.af.mil> Dave Chapeskie <dchapes@zeus.leitch.com> Dave Edmondson <davided@sco.com> Dave Rivers <rivers@ponds.uucp> David Dawes <dawes@physics.su.OZ.AU> David Leonard <d@scry.dstc.edu.au> David O'Brien <obrien@cs.ucdavis.edu> Dean Huxley <dean@fsa.ca> Dirk Froemberg <dirk@hal.in-berlin.de> Don Whiteside <dwhite@anshar.shadow.net> Don Yuniskis <dgy@rtd.com> Donald Burr <d_burr@ix.netcom.com> Doug Ambrisko <ambrisko@ambrisko.roble.com> Eric Blood <eblood@cs.unr.edu> Frank Bartels <knarf@camelot.de> Frank Maclachlan <fpm@crash.cts.com> Frank Nobis <fn@trinity.radio-do.de> Gary A. Browning <gab10@griffcd.amdahl.com> Gene Stark <stark@cs.sunysb.edu> Greg Ungerer <gerg@stallion.oz.au> Harlan Stenn <Harlan.Stenn@pfcs.com> Havard Eidnes <Havard.Eidnes@runit.sintef.no> Hideaki Ohmon <ohmon@sfc.keio.ac.jp> Hidekazu Kuroki <hidekazu@cs.titech.ac.jp> Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp> Holger Veit <Holger.Veit@gmd.de> Ishii Masahiro, R. Kym Horsell J.T. Conklin <jtc@cygnus.com> James Clark <jjc@jclark.com> James da Silva <jds@cs.umd.edu> et al Janusz Kokot <janek@gaja.ipan.lublin.pl> Javier Martin Rueda <jmrueda@diatel.upm.es> Jian-Da Li <jdli@FreeBSD.csie.NCTU.edu.tw> Jim Lowe <james@miller.cs.uwm.edu> Jim Wilson <wilson@moria.cygnus.com> Johann Tonsing <jtonsing@mikom.csir.co.za> John Capo <jc@irbs.com> John Perry <perry@vishnu.alias.net> Juergen Lock <nox@jelal.hb.north.de> Julian Jenkins <kaveman@magna.com.au> Julian Stacey <jhs@freebsd.org> Keith Bostic <bostic@toe.CS.Berkeley.EDU> Keith Moore <?> Kirk McKusick <mckusick@mckusick.com> Kostya Lukin <lukin@okbmei.msk.su> Kurt Olsen <kurto@tiny.mcs.usu.edu> Lucas James <Lucas.James@ldjpc.apana.org.au> Marc Frajola <marc@dev.com> Marc Ramirez <mrami@mramirez.sy.yale.edu Marc van Kempen <wmbfmk@urc.tue.nl> Mark Huizer <xaa@stack.urc.tue.nl> Mark Tinguely <tinguely@plains.nodak.edu> <tinguely@hookie.cs.ndsu.NoDak.edu> Martin Birgmeier Masachika ISHIZUKA <ishizuka@isis.min.ntt.jp> Masafumi Nakane <max@sfc.wide.ad.jp> Matt Bartley <mbartley@lear35.cytex.com> Matt Thomas <thomas@lkg.dec.com> Matt White <mwhite+@CMU.EDU> Matthew N. Dodd <winter@jurai.net> Matthew Stein <matt@bdd.net> Michael Elbel <me@FreeBSD.ORG> Michael Smith <msmith@atrad.adelaide.edu.au> Mikael Hybsch <micke@dynas.se> Mike Peck <mike@binghamton.edu> MITA Yoshio <mita@iis.u-tokyo.ac.jp> NIIMI Satoshi <sa2c@and.or.jp> Nisha Talagala <nisha@cs.berkeley.edu> Nobuhiro Yasutomi <nobu@psrc.isac.co.jp> Nobuyuki Koganemaru <kogane@kces.koganemaru.co.jp> Noritaka Ishizumi <graphite@taurus.bekkoame.or.jp> Paul Kranenburg <pk@cs.few.eur.nl> Paul Mackerras <paulus@cs.anu.edu.au> Peter Stubbs <PETERS@staidan.qld.edu.au> Philippe Charnier <charnier@lirmm.fr> Randall Hopper <rhh@stealth.ct.picker.com> Richard Stallman <rms@gnu.ai.mit.edu> Richard Wiwatowski <rjwiwat@adelaide.on.neti> Rob Shady <rls@id.net> Rob Snow <rsnow@txdirect.net> Robert Sanders <rsanders@mindspring.com> Sascha Wildner <swildner@channelz.GUN.de> Scott Blachowicz <scott@sabami.seaslug.org> Serge V. Vakulenko <vak@zebub.msk.su> Soren Dayton <csdayton@midway.uchicago.edu> Stephen McKay <syssgm@devetir.qld.gov.au> Steve Gerakines <steve2@genesis.tiac.net> Steve Passe <smp@csn.net> Taguchi Takeshi <taguchi@tohoku.iij.ad.jp> Tatsumi Hosokawa <hosokawa@mt.cs.keio.ac.jp> Terry Lambert <terry@lambert.org> Terry Lee <terry@uivlsi.csl.uiuc.edu> Theo Deraadt <deraadt@fsa.ca> Thomas Gellekum <thomas@ghpc8.ihf.rwth-aachen.de> Tim Kientzle <kientzle@netcom.com> Tom Samplonius <tom@misery.sdf.com> Torbjorn Granlund <tege@matematik.su.se> Werner Griessl <werner@btp1da.phy.uni-bayreuth.de> Wes Santee <wsantee@wsantee.oz.net> Wolfgang Stanglmeier <wolf@kintaro.cologne.de> Yoshiro Mihira <sanpei@yy.cs.keio.ac.jp> Yuval Yarom <yval@cs.huji.ac.il> Yves Fonk <yves@cpcoup5.tn.tudelft.nl> 386BSD Patch kit patch contributors

(in alphabetical order by first name): Adam Glass <glass@postgres.berkeley.edu> Adrian Hall <adrian@ibmpcug.co.uk> Andrey A. Chernov <ache@astral.msk.su> Andrew Herbert <andrew@werple.apana.org.au> Andrew Moore <alm@netcom.com> Andy Valencia <ajv@csd.mot.com> <jtk@netcom.com> Arne Henrik Juul <arnej@Lise.Unit.NO> Bakul Shah <bvs@bitblocks.com> Barry Lustig <barry@ictv.com> Bob Wilcox <bob@obiwan.uucp> Branko Lankester Brett Lymn <blymn@mulga.awadi.com.AU> Charles Hannum <mycroft@ai.mit.edu> Chris G. Demetriou <cgd@postgres.berkeley.edu> Chris Torek <torek@ee.lbl.gov> Christoph Robitschko <chmr@edvz.tu-graz.ac.at> Daniel Poirot <poirot@aio.jsc.nasa.gov> Dave Burgess <burgess@hrd769.brooks.af.mil> Dave Rivers <rivers@ponds.uucp> David Dawes <dawes@physics.su.OZ.AU> David Greenman <davidg@Root.COM> Eric J. Haug <ejh@slustl.slu.edu> Felix Gaehtgens <felix@escape.vsse.in-berlin.de> Frank Maclachlan <fpm@crash.cts.com> Gary A. Browning <gab10@griffcd.amdahl.com> Geoff Rehmet <csgr@alpha.ru.ac.za> Goran Hammarback <goran@astro.uu.se> Guido van Rooij <guido@gvr.win.tue.nl> Guy Harris <guy@auspex.com> Havard Eidnes <Havard.Eidnes@runit.sintef.no> Herb Peyerl <hpeyerl@novatel.cuc.ab.ca Holger Veit <Holger.Veit@gmd.de> Ishii Masahiro, R. Kym Horsell J.T. Conklin <jtc@cygnus.com> Jagane D Sundar < jagane@netcom.com > James Clark <jjc@jclark.com> James Jegers <jimj@miller.cs.uwm.edu> James W. Dolter James da Silva <jds@cs.umd.edu> et al Jay Fenlason <hack@datacube.com> Jim Wilson <wilson@moria.cygnus.com> Jörg Lohse <lohse@tech7.informatik.uni-hamburg.de> Jörg Wunsch <joerg_wunsch@uriah.heep.sax.de> John Dyson - <formerly dyson@ref.tfs.com> John Polstra <jdp@polstra.com> John Woods <jfw@eddie.mit.edu> Jordan K. Hubbard <jkh@whisker.hubbard.ie> Julian Elischer <julian@dialix.oz.au> Julian Stacey <jhs@freebsd.org> Karl Lehenbauer <karl@NeoSoft.com> <karl@one.neosoft.com> Keith Bostic <bostic@toe.CS.Berkeley.EDU> Ken Hughes Kent Talarico <kent@shipwreck.tsoft.net> Kevin Lahey <kml%rokkaku.UUCP@mathcs.emory.edu> <kml@mosquito.cis.ufl.edu> Marc Frajola <marc@dev.com> Mark Tinguely <tinguely@plains.nodak.edu> <tinguely@hookie.cs.ndsu.NoDak.edu> Martin Renters <martin@tdc.on.ca> Michael Galassi <nerd@percival.rain.com> Mike Durkin <mdurkin@tsoft.sf-bay.org> Naoki Hamada <nao@sbl.cl.nec.co.jp> Nate Williams <nate@bsd.coe.montana.edu> Nick Handel <nhandel@NeoSoft.com> <nick@madhouse.neosoft.com> Pace Willisson <pace@blitz.com> Paul Kranenburg <pk@cs.few.eur.nl> Paul Mackerras <paulus@cs.anu.edu.au> Paul Popelka <paulp@uts.amdahl.com> Peter da Silva <peter@NeoSoft.com> Phil Sutherland <philsuth@mycroft.dialix.oz.au> Poul-Henning Kamp<phk@FreeBSD.ORG> Ralf Friedl <friedl@informatik.uni-kl.de> Rick Macklem <root@snowhite.cis.uoguelph.ca> Robert D. Thrush <rd@phoenix.aii.com> Rodney W. Grimes <rgrimes@cdrom.com> Rog Egge <?> Sascha Wildner <swildner@channelz.GUN.de> Scott Burris <scott@pita.cns.ucla.edu> Scott Reynolds <scott@clmqt.marquette.mi.us> Sean Eric Fagan <sef@kithrup.com> Simon J Gerraty <sjg@melb.bull.oz.au> <sjg@zen.void.oz.au> Stephen McKay <syssgm@devetir.qld.gov.au> Terry Lambert <terry@icarus.weber.edu> Terry Lee <terry@uivlsi.csl.uiuc.edu> Warren Toomey <wkt@csadfa.cs.adfa.oz.au> Wiljo Heinen <wiljo@freeside.ki.open.de> William Jolitz <withheld> Wolfgang Solfrank <ws@tools.de> Wolfgang Stanglmeier <wolf@dentaro.GUN.de> Yuval Yarom <yval@cs.huji.ac.il> diff --git a/handbook/handbook.sgml b/handbook/handbook.sgml index 9ef42f4f4b..549ce67a5d 100644 --- a/handbook/handbook.sgml +++ b/handbook/handbook.sgml @@ -1,171 +1,171 @@ - + %authors; %lists; %sections; ]> FreeBSD Handbook <author> <name>The FreeBSD Documentation Project</name> </author> <date>July 1996</date> <abstract>Welcome to FreeBSD! This handbook covers the installation and day to day use of <bf>FreeBSD Release &rel.current;</bf>. This manual is a <bf>work in progress</bf> and is the work of many individuals. Many sections do not yet exist and some of those that do exist need to be updated. If you are interested in helping with this project, send email to the &a.doc The latest version of this document is always available from the <url url="http://www.FreeBSD.ORG/" name="FreeBSD World Wide Web server">. It may also be downloaded in ascii, LaTeX, postscript or HTML from the <url url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/docs" name="FreeBSD FTP server"> or one of the numerous <ref id="mirrors" name="mirror sites">. </abstract> <toc> <!-- ************************************************************ --> <part><heading>Basics</heading> <chapt><heading>Introduction</heading> - <p>FreeBSD is a 4.4 BSD Lite based operating system for Intel + <p>FreeBSD is a 4.4BSD-Lite based operating system for Intel architecture (x86) based PCs. For an overview of FreeBSD, see <ref id="nutshell" name="FreeBSD in a nutshell">. For a history of the project, read <ref id="history" name="a brief history of FreeBSD">. To see a description of the latest release, read <ref id="relnotes" name="about the current release">. If you're interested in contributing something to the FreeBSD project (code, equipment, sacks of unmarked bills), please see about <ref id="submitters" name="contributing to FreeBSD">. &nutshell; &history; &goals; &relnotes; &install; &basics; <chapt><heading>Installing applications</heading> <sect><heading>* Installing packages</heading> &ports; <!-- ************************************************************ --> <part><heading>System Administration</heading> &kernelconfig; <chapt><heading>Users, groups and security</heading> &crypt; &skey; &kerberos; &firewalls; &printing; "as; <chapt><heading>The X-Window System</heading> <p>Pending the completion of this section, please refer to documentation supplied by the <url url="http://www.xfree86.org/" name="The XFree86 Project, Inc">. &hw; <!-- ************************************************************ --> <part><heading>Network Communications</heading> <chapt><heading>Basic Networking</heading> <sect><heading>* Ethernet basics</heading> <sect><heading>* Serial basics</heading> &term; &dialup; <chapt><heading>PPP and SLIP</heading> <p>If your connection to the Internet is through a modem, or you wish to provide other people with dialup connections to the Internet using FreeBSD, you have the option of using PPP or SLIP. Furthermore, two varieties of PPP are provided: <em>user</em> (sometimes referred to as iijppp) and <em>kernel</em>. The procedures for configuring both types of PPP, and for setting up SLIP are described in this chapter. &userppp; &ppp; &slipc; &slips; <chapt><heading>Advanced networking</heading> &routing; &nfs; &diskless; <sect><heading>* Yellow Pages/NIS</heading> &isdn; <chapt><heading>* Mail</heading> <!-- ************************************************************ --> <part><heading>Advanced topics</heading> ¤t; &stable; &synching; &submitters; &troubleshooting; &kerneldebug; &linuxemu; <chapt><heading>FreeBSD internals</heading> &booting; &memoryuse; &dma; <!-- ************************************************************ --> <part><heading>Appendices</heading> &mirrors; &bibliography; &eresources; &contrib; &policies; &pgpkeys; <!-- &glossary; --> </book> </linuxdoc> diff --git a/handbook/history.sgml b/handbook/history.sgml index d247053f6e..17d0570b29 100644 --- a/handbook/history.sgml +++ b/handbook/history.sgml @@ -1,116 +1,116 @@ -<!-- $Id: history.sgml,v 1.14 1996-05-16 23:17:59 mpp Exp $ --> +<!-- $Id: history.sgml,v 1.15 1996-08-21 07:28:45 asami Exp $ --> <!-- The FreeBSD Documentation Project --> <sect><heading>A brief history of FreeBSD<label id="history"></heading> <p><em>Contributed by &a.jkh;</em>. The FreeBSD project had its genesis in the early part of 1993, partially as an outgrowth of the "Unofficial 386BSD Patchkit" by the patchkit's last 3 coordinators: Nate Williams, Rod Grimes and myself. David Greenman and Julian Elischer were also lurking in the background around this time, though they did not come fully into the project until a month or two after it was more or less officially launched. Our original goal was to produce an intermediate snapshot of 386BSD in order to fix a number of problems with it that the patchkit mechanism just was not capable of solving. Some of you may remember the early working title for the project being "386BSD 0.5" or "386BSD Interim" in reference to that fact. 386BSD was Bill Jolitz's operating system, which had been up to that point suffering rather severely from almost a year's worth of neglect. As the patchkit swelled ever more uncomfortably with each passing day, we were in unanimous agreement that something had to be done and decided to try and assist Bill by providing this interim "cleanup" snapshot. Those plans came to a rude halt when Bill Jolitz suddenly decided to withdraw his sanction from the project and without any clear indication of what would be done instead. It did not take us long to decide that the goal remained worthwhile even without Bill's support, and so we adopted the name "FreeBSD", which was coined by David Greenman. Our initial objectives were set after consulting with the system's current users, and once it became clear that the project was on the road to perhaps even becoming a reality, I contacted Walnut Creek CDROM with an eye towards improving FreeBSD's distribution channels for those many unfortunates without easy access to the Internet. Walnut Creek CDROM not only supported the idea of distributing FreeBSD on CD but went so far as to provide the project with a machine to work on and a fast Internet connection. Without Walnut Creek CDROM's almost unprecedented degree of faith in what was, at the time, a completely unknown project, it is quite unlikely that FreeBSD would have gotten as far, as fast, as it has today. The first CDROM (and general net-wide) distribution was FreeBSD 1.0, -released in December of 1993. This was based on the 4.3 BSD Lite +released in December of 1993. This was based on the 4.3BSD-Lite ("Net/2") tape from U.C. Berkeley, with many components also provided by 386BSD and the Free Software Foundation. It was a fairly reasonable success for a first offering, and we followed it with the highly successful FreeBSD 1.1 release in May of 1994. Around this time, some rather unexpected storm clouds formed on our horizon as Novell and U.C. Berkeley settled their long-running lawsuit over the legal status of the Berkeley Net/2 tape. A condition of that settlement was U.C. Berkeley's concession that large parts of Net/2 were "encumbered" code and the property of Novell, who had in turn acquired it from AT&T some time previously. What Berkeley got in return was -Novell's "blessing" that the 4.4 Lite release, when it was finally +Novell's "blessing" that the 4.4BSD-Lite release, when it was finally released, would be declared unencumbered and all existing Net/2 users would be strongly encouraged to switch. This included us, and we were given until the end of July 1994 to stop shipping our own Net/2 based product. Under the terms of that agreement, we were allowed one last release before the deadline and that became FreeBSD 1.1.5.1, the culmination of our year's work with Net/2 and generally considered by many to be a significant project milestone for stability and general performance.. We then set about the arduous task of literally re-inventing ourselves -with a completely new and rather incomplete set of 4.4 Lite bits. The +with a completely new and rather incomplete set of 4.4BSD-Lite bits. The "Lite" releases were light in part because Berkeley's CSRG had removed large chunks of code required for actually constructing a bootable running system (due to various legal requirements) and the fact that the Intel port of 4.4 was highly incomplete. It took us until December of 1994 to make this transition, and in January of 1995 we released FreeBSD 2.0 to the net and on CDROM. Despite being still more than a little rough around the edges, the release was a significant success and has since been followed by the more robust and easier to install FreeBSD 2.0.5 release in June of 1995. <em>Where to from here?</em> We just released FreeBSD 2.1.0 on November 19th, 1995 and, by all accounts, people are pretty happy with it. We will therefore continue with the 2.1-STABLE branch of FreeBSD (which actually began with 2.0.5) well into Q1 of 1996 with at least one additional release: FreeBSD 2.1.1. A 2.1.2 release may follow 2.1.1, though this will depend heavily on the status of FreeBSD 2.2 in Q2 of 1996. 2.2 is our development branch, where long term projects for everything from NFS v3 to PCCARD support are currently taking place. Preliminary timelines suggest that development in 2.2 will begin slowing down and early release engineering simulations (2.2 SNAPshots) started in Q1 of 1996. Given a favorable prognosis for 2.2's general health, a migration to 2.2 will then begin in early Q2 of 1996 and a new 2.3 branch created for next-generation development. Around the time that 2.2-RELEASE is produced (late Q2 1996), the 2.1.x lineage will also be phased out. We also intend to focus on any remaining areas of weakness, like documentation or missing drivers, and steadily increase the overall quality and feature set of the system well into 1996 and beyond. Now might also be a good time to note that the development of FreeBSD is <em>not</em> a closed process, despite some popular misconceptions to the contrary, and anyone is free to contribute code or ideas. Once a contributor has established a reasonable track record for reliability, we generally, in fact, give them write access to the project's CVS repository, where their changes can propagate automatically to other users of FreeBSD. Our centralized development model is designed for the convenience of the <em>users</em> of FreeBSD, who are thereby provided with an easy way of tracking one central code base, not to keep potential contributors out! Individuals who hae shown a consistent and significant dedication to the project are even often asked to join the FreeBSD core team to help in setting the project's overall directions and goals, so truly no part of the project is closed to additional members. All we ask of those wishing for closer ties to this project is some of the same dedication its current members have to its continued success! diff --git a/handbook/kerberos.sgml b/handbook/kerberos.sgml index 1a5eea48a0..d9197e1d42 100644 --- a/handbook/kerberos.sgml +++ b/handbook/kerberos.sgml @@ -1,480 +1,480 @@ -<!-- $Id: kerberos.sgml,v 1.7 1996-05-16 23:18:02 mpp Exp $ --> +<!-- $Id: kerberos.sgml,v 1.8 1996-08-21 07:28:48 asami Exp $ --> <!-- The FreeBSD Documentation Project --> <sect><heading>Kerberos<label id="kerberos"></heading> <p><em>Contributed by &a.markm; (based on contribution by &a.md;).</em> Kerberos is a network add-on system/protocol that allows users to authenticate themselves through the services of a secure server. Services such as remote login, remote copy, secure inter-system file copying and other high-risk tasks are made considerably safer and more controllable. The following instructions can be used as a guide on how to set up Kerberos as distributed for FreeBSD. However, you should refer to the relevant manual pages for a complete description. - In FreeBSD, the Kerberos is not that from the original 4.4 BSD, + In FreeBSD, the Kerberos is not that from the original 4.4BSD-Lite, distribution, but eBones, which had been previously ported to FreeBSD 1.1.5.1, and was sourced from outside the USA/Canada, and is thus available to system owners outside those countries. For those needing to get a legal foreign distribution of this software, please <em>DO NOT</em> get it from a USA or Canada site. You will get that site in <em>big</em> trouble! A legal copy of this is available from <tt>skeleton.mikom.csir.co.za</tt>, which is in South Africa. <sect1> <heading>Creating the initial database</heading> <p>This is done on the Kerberos server only. First make sure that your do not have any old Kerberos databases around. You should change to the directory <tt>/etc/kerberosIV</tt> and check that only the following files are present: <tscreen><verb> grunt# cd /etc/kerberosIV grunt# ls README krb.conf krb.realms </verb></tscreen> <p>If any additional files (such as <tt>principal.*</tt> or <tt>master_key</tt>) exist, then use the <tt>kdb_destroy</tt> command to destroy the old Kerberos database, of if Kerberos is not running, simply delete the extra files with <tt>rm</tt>. You should now edit the <tt>krb.conf</tt> and <tt>krb.realms</tt> files to define your Kerberos realm. In this case the realm will be <it>GRONDAR.ZA</it> and the server is <it>grunt.grondar.za</it>. We edit or create the <tt>krb.conf</tt> file: <tscreen><verb> grunt# cat krb.conf GRONDAR.ZA GRONDAR.ZA grunt.grondar.za admin server CS.BERKELEY.EDU okeeffe.berkeley.edu ATHENA.MIT.EDU kerberos.mit.edu ATHENA.MIT.EDU kerberos-1.mit.edu ATHENA.MIT.EDU kerberos-2.mit.edu ATHENA.MIT.EDU kerberos-3.mit.edu LCS.MIT.EDU kerberos.lcs.mit.edu TELECOM.MIT.EDU bitsy.mit.edu ARC.NASA.GOV trident.arc.nasa.gov </verb></tscreen> <p>In this case, the other realms do not need to be there. They are here as an example of how a machine may be made aware of multiple realms. You may wish to not include them for simplicity. The first line names the realm in which this system works. The other lines contain realm/host entries. The first item on a line is a realm, and the second is a host in that realm that is acting as a ``key distribution centre''. The words ``admin server'' following a hosts name means that host also provides an administrative database server. For further explanation of these terms, please consult the Kerberos man pages. Now we have to add <it>grunt.grondar.za</it> to the <it>GRONDAR.ZA</it> realm and also add an entry to put all hosts in the <it>.grondar.za</it> domain in the <it>GRONDAR.ZA</it> realm. The <tt>krb.realms</tt> file would be updated as follows: <tscreen><verb> grunt# cat krb.realms grunt.grondar.za GRONDAR.ZA .grondar.za GRONDAR.ZA .berkeley.edu CS.BERKELEY.EDU .MIT.EDU ATHENA.MIT.EDU .mit.edu ATHENA.MIT.EDU </verb></tscreen> <p>Again, the other realms do not need to be there. They are here as an example of how a machine may be made aware of multiple realms. You may wish to remove them to simplify things. The first line puts the <it>specific</it> system into the named realm. The rest of the lines show how to default systems of a particular subdomain to a named realm. Now we are ready to create the database. This only needs to run on the Kerberos server (or Key Distribution Centre). Issue the <tt>kdb_init</tt> command to do this: <tscreen><verb> grunt# kdb_init Realm name [default ATHENA.MIT.EDU ]: GRONDAR.ZA You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter Kerberos master key: </verb></tscreen> <p>Now we have to save the key so that servers on the local machine can pick it up. Use the <tt>kstash</tt> command to do this. <tscreen><verb> grunt# kstash Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! </verb></tscreen> <p>This saves the encrypted master password in <tt>/etc/kerberosIV/master_key</tt>. <sect1> <heading>Making it all run</heading> <p>Two principals need to be added to the database for <it>each</it> system that will be secured with Kerberos. Their names are <tt>kpasswd</tt> and <tt>rcmd</tt> These two principals are made for each system, with the instance being the name of the individual system. These daemons, <tt>kpasswd</tt> and <tt>rcmd</tt> allow other systems to change Kerberos passwords and run commands like <tt>rcp</tt>, <tt>rlogin</tt> and <tt>rsh</tt>. Now lets add these entries: <tscreen><verb> grunt# kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: passwd Instance: grunt <Not found>, Create [y] ? y Principal: passwd, Instance: grunt, kdc_key_ver: 1 New Password: <---- enter RANDOM here Verifying password New Password: <---- enter RANDOM here Random password [y] ? y Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: rcmd Instance: grunt <Not found>, Create [y] ? Principal: rcmd, Instance: grunt, kdc_key_ver: 1 New Password: <---- enter RANDOM here Verifying password New Password: <---- enter RANDOM here Random password [y] ? Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit </verb></tscreen> <sect1> <heading>Creating the server file</heading> <p>We now have to extract all the instances which define the services on each machine. For this we use the <tt>ext_srvtab</tt> command. This will create a file which must be copied or moved <it>by secure means</it> to each Kerberos client's /etc/kerberosIV directory. This file must be present on each server and client, and is crucial to the operation of Kerberos. <tscreen><verb> grunt# ext_srvtab grunt Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'grunt-new-srvtab'.... </verb></tscreen> <p>Now, this command only generates a temporary file which must be renamed to <tt>srvtab</tt> so that all the server can pick it up. Use the <tt>mv</tt> command to move it into place on the original system: <tscreen><verb> grunt# mv grunt-new-srvtab srvtab </verb></tscreen> <p>If the file is for a client system, and the network is not deemed safe, then copy the <tt><client>-new-srvtab</tt> to removable media and transport it by secure physical means. Be sure to rename it to <tt>srvtab</tt> in the client's <tt>/etc/kerberosIV</tt> directory, and make sure it is mode 600: <tscreen><verb> grumble# mv grumble-new-srvtab srvtab grumble# chmod 600 srvtab </verb></tscreen> <sect1> <heading>Populating the database</heading> <p>We now have to add some user entries into the database. First lets create an entry for the user <it>jane</it>. Use the <tt>kdb_edit</tt> command to do this: <tscreen><verb> grunt# kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: <Not found>, Create [y] ? y Principal: jane, Instance: , kdc_key_ver: 1 New Password: <---- enter a secure password here Verifying password New Password: <---- re-enter the password here Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit </verb></tscreen> <sect1> <heading>Testing it all out</heading> <p>First we have to start the Kerberos daemons. NOTE that if you have correctly edited your <tt>/etc/sysconfig</tt> then this will happen automatically when you reboot. This is only necessary on the Kerberos server. Kerberos clients will automagically get what they need from the <tt>/etc/kerberosIV</tt> directory. <tscreen><verb> grunt# kerberos & grunt# Kerberos server starting Sleep forever on error Log file is /var/log/kerberos.log Current Kerberos master key version is 1. Master key entered. BEWARE! Current Kerberos master key version is 1 Local realm: GRONDAR.ZA grunt# kadmind -n & grunt# KADM Server KADM0.0A initializing Please do not use 'kill -9' to kill this job, use a regular kill instead Current Kerberos master key version is 1. Master key entered. BEWARE! </verb></tscreen> <p>Now we can try using the <tt>kinit</tt> command to get a ticket for the id <it>jane</it> that we created above: <tscreen><verb> grunt$ kinit jane MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jane" Password: </verb></tscreen> <p>Try listing the tokens using <tt>klist</tt> to see if we really have them: <tscreen><verb> grunt$ klist Ticket file: /tmp/tkt245 Principal: jane@GRONDAR.ZA Issued Expires Principal Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA </verb></tscreen> <p>Now try changing the password using <tt>passwd</tt> to check if the kpasswd daemon can get authorization to the Kerberos database: <tscreen><verb> grunt$ passwd realm GRONDAR.ZA Old password for jane: New Password for jane: Verifying password New Password for jane: Password changed. </verb></tscreen> <sect1> <heading>Adding <tt>su</tt> privileges</heading> <p>Kerberos allows us to give <it>each</it> user who needs root privileges their own <it>separate</it> <tt>su</tt>password. We could now add an id which is authorized to <tt>su</tt> to <it>root</it>. This is controlled by having an instance of <it>root</it> associated with a principal. Using <tt>kdb_edit</tt> we can create the entry <it>jane.root</it> in the Kerberos database: <tscreen><verb> grunt# kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: root <Not found>, Create [y] ? y Principal: jane, Instance: root, kdc_key_ver: 1 New Password: <---- enter a SECURE password here Verifying password New Password: <---- re-enter the password here Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Keep this short! Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit </verb></tscreen> <p>Now try getting tokens for it to make sure it works: <tscreen><verb> grunt# kinit jane.root MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jane.root" Password: </verb></tscreen> <p>Now we need to add the user to root's <tt>.klogin</tt> file: <tscreen><verb> grunt# cat /root/.klogin jane.root@GRONDAR.ZA </verb></tscreen> <p>Now try doing the <tt>su</tt>: <tscreen><verb> [jane@grunt 10407] su Password: grunt# </verb></tscreen> and take a look at what tokens we have: <tscreen><verb> grunt# klist Ticket file: /tmp/tkt_root_245 Principal: jane.root@GRONDAR.ZA Issued Expires Principal May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA </verb></tscreen> <sect1> <heading>Using other commands</heading> <p>In an earlier example, we created a principal called <tt>jane</tt> with an instance <tt>root</tt>. This was based on a user with the same name as the principal, and this is a Kerberos default; that a <em><principal>.<instance></em> of the form <em><username>.</em><tt>root</tt> will allow that <em><username></em> to <tt>su</tt> to root if the necessary entries are in the <tt>.klogin</tt> file in <tt>root</tt>'s home directory: <tscreen><verb> grunt# cat /root/.klogin jane.root@GRONDAR.ZA </verb></tscreen> <p>Likewise, if a user has in their own home directory lines of the form: <tscreen><verb> [jane@grunt 10543] cat ~/.klogin jane@GRONDAR.ZA jack@GRONDAR.ZA </verb></tscreen> <p>This allows anyone in the <em>GRONDAR.ZA</em> realm who has authenticated themselves to <em>jane</em> or <em>jack</em> (via <tt>kinit</tt>, see above) access to <tt>rlogin</tt> to <em>jane</em>'s account or files on this system (<em>grunt</em>) via <tt>rlogin</tt>, <tt>rsh</tt> or <tt>rcp</tt>. For example, Jane now logs into another system, using Kerberos: <tscreen><verb> [jane@grumble 573] kinit MIT Project Athena (grunt.grondar.za) Password: [jane@grumble 574] rlogin grunt Last login: Mon May 1 21:14:47 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 [jane@grunt 10567] </verb></tscreen> <p>Or Jack logs into Jane's account on the same machine (Jane having set up the <tt>.klogin</tt> file as above, and the person in charge of Kerberos having set up principal <em>jack</em> with a null instance: <tscreen><verb> [jack@grumble 573] kinit [jack@grumble 574] rlogin grunt -l jane MIT Project Athena (grunt.grondar.za) Password: Last login: Mon May 1 21:16:55 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 [jane@grunt 10578] </verb></tscreen> diff --git a/handbook/kernelconfig.sgml b/handbook/kernelconfig.sgml index efd529cb6c..e21fabbc8d 100644 --- a/handbook/kernelconfig.sgml +++ b/handbook/kernelconfig.sgml @@ -1,1277 +1,1277 @@ -<!-- $Id: kernelconfig.sgml,v 1.14 1996-08-15 11:20:14 asami Exp $ --> +<!-- $Id: kernelconfig.sgml,v 1.15 1996-08-21 07:28:50 asami Exp $ --> <!-- The FreeBSD Documentation Project --> <!-- <!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'> --> <chapt><heading>Configuring the FreeBSD Kernel<label id="kernelconfig"></heading> <p><em>Contributed by &a.jehamby;.<newline>6 October 1995.</em> This large section of the handbook discusses the basics of building your own custom kernel for FreeBSD. This section is appropriate for both novice system administrators and those with advanced Unix experience. <sect><heading>Why build a custom kernel?</heading> <p>Building a custom kernel is one of the most important rites of passage every Unix system administrator must learn. This process, while time-consuming, will provide many benefits to your FreeBSD system. Unlike the GENERIC kernel, which must support every possible SCSI and network card, along with tons of other rarely used hardware support, a custom kernel only contains support for <em>your</em> PC's hardware. This has a number of benefits: <itemize> <item>It will take less time to boot because it does not have to spend time probing for hardware which you do not have. <item>A custom kernel often uses less memory, which is important because the kernel is the one process which must always be present in memory, and so all of that unused code ties up pages of RAM that your programs would otherwise be able to use. Therefore, on a system with limited RAM, building a custom kernel is of critical importance. <item>Finally, there are several kernel options which you can tune to fit your needs, and device driver support for things like sound cards which you can include in your kernel but are <em>not</em> present in the GENERIC kernel. </itemize></p> <sect><heading>Building and Installing a Custom Kernel<label id="kernelconfig:building"></heading> <p>First, let us take a quick tour of the kernel build directory. All directories mentioned will be relative to the main <tt>/usr/src/sys</tt> directory, which is also accessible through <tt>/sys</tt>. There are a number of subdirectories here representing different parts of the kernel, but the most important, for our purposes, are <tt>i386/conf</tt>, where you will edit your custom kernel configuration, and <tt>compile</tt>, which is the staging area where your kernel will be built. Notice the logical organization of the directory tree, with each supported device, filesystem, and option in its own subdirectory. Also, anything inside the <tt>i386</tt> directory deals with PC hardware only, while everything outside the <tt>i386</tt> directory is common to all platforms which FreeBSD could potentially be ported to. <quote><em/Note:/ If there is <em>not</em> a <tt>/usr/src/sys</tt> directory on your system, then the kernel source has not been been installed. Follow the instructions for installing packages to add this package to your system.</quote> Next, move to the <tt>i386/conf</tt> directory and copy the GENERIC configuration file to the name you want to give your kernel. For example: <tscreen><verb> # cd /usr/src/sys/i386/conf # cp GENERIC MYKERNEL </verb></tscreen> Traditionally, this name is in all capital letters and, if you are maintaining multiple FreeBSD machines with different hardware, it is a good idea to name it after your machine's hostname. We will call it MYKERNEL for the purpose of this example. <quote><em/Note:/ You must execute these and all of the following commands under the root account or you will get ``permission denied'' errors.</quote> Now, edit MYKERNEL with your favorite text editor. If you're just starting out, the only editor available will probably be <tt>vi</tt>, which is too complex to explain here, but is covered well in many books in the <ref id="bibliography" name="bibliography">. Feel free to change the comment lines at the top to reflect your configuration or the changes you have made to differentiate it from GENERIC. If you have build a kernel under SunOS or some other BSD operating system, much of this file will be very familiar to you. If you are coming from some other operating system such as DOS, on the other hand, the GENERIC configuration file might seem overwhelming to you, so follow the descriptions in the <ref id="kernelconfig:config" name="Configuration File"> section slowly and carefully. <quote><em/Note:/ If you are trying to upgrade your kernel from an older version of FreeBSD, you will probably have to get a new version of <tt>config(8)</tt> from the same place you got the new kernel sources. It is located in <tt>/usr/src/usr.sbin</tt>, so you will need to download those sources as well. Re-build and install it before running the next commands.</quote> When you are finished, type the following to compile and install your kernel: <tscreen><verb> # /usr/sbin/config MYKERNEL # cd ../../compile/MYKERNEL # make depend # make # make install </verb></tscreen> The new kernel will be copied to the root directory as <tt>/kernel</tt> and the old kernel will be moved to <tt>/kernel.old</tt>. Now, shutdown the system and reboot to use your kernel. In case something goes wrong, there are some <ref id="kernelconfig:trouble" name= "troubleshooting"> instructions at the end of this document. Be sure to read the section which explains how to recover in case your new kernel <ref id="kernelconfig:noboot" name="does not boot">. <quote><em/Note:/ If you have added any new devices (such as sound cards) you may have to add some <ref id="kernelconfig:nodes" name="device nodes"> to your <tt>/dev</tt> directory before you can use them.</quote> <sect><heading>The Configuration File<label id="kernelconfig:config"></heading> <p>The general format of a configuration file is quite simple. Each line contains a keyword and one or more arguments. For simplicity, most lines only contain one argument. Anything following a <tt>#</tt> is considered a comment and ignored. The following sections describe each keyword, generally in the order they are listed in GENERIC, although some related keywords have been grouped together in a single section (such as Networking) even though they are actually scattered throughout the GENERIC file. An exhaustive list of options and more detailed explanations of the device lines is present in the LINT configuration file, located in the same directory as GENERIC. If you are in doubt as to the purpose or necessity of a line, check first in LINT. <p>The kernel is currently being moved to a better organization of the option handling. Traditionally, each option in the config file was simply converted into a <tt>-D</tt> switch for the <tt>CFLAGS</tt> line of the kernel Makefile. Naturally, this caused a creaping optionism, with nobody really knowing which option has been referenced in what files. <p>In the new scheme, every <tt>#ifdef</tt> that is intended to be dependant upon an option gets this option out of an <tt>opt_<em>foo</em>.h</tt> declaration file created in the compile directory by <tt>config</tt>. The list of valid options for <tt>config</tt> lives in two files: options that do not depend on the architecture are listed in <tt>/sys/conf/options</tt>, architecture-dependant ones in <tt>/sys/<em>arch</em>/conf/options.<em>arch</em></tt>, with <em>arch</em> being for example <tt>i386</tt>. <sect1><heading>Mandatory Keywords</heading> <p>These keywords are required in every kernel you build. <descrip> <tag>machine ``i386''</tag> <p>The first keyword is <tt>machine</tt>, which, since FreeBSD only runs on Intel 386 and compatible chips, is i386. <quote><em>Note:</em> that any keyword which contains numbers used as text must be enclosed in quotation marks, otherwise <tt>config</tt> gets confused and thinks you mean the actual number 386.</quote> <tag>cpu ``<em>cpu_type</em>''</tag> <p>The next keyword is <tt>cpu</tt>, which includes support for each CPU supported by FreeBSD. The possible values of <tt><em>cpu_type</em></tt> include: <itemize> <item>I386_CPU <item>I486_CPU <item>I586_CPU </itemize> and multiple instances of the <tt>cpu</tt> line may be present with different values of <tt><em>cpu_type</em></tt> as are present in the GENERIC kernel. For a custom kernel, it is best to specify only the cpu you have. If, for example, you have an Intel Pentium, use <tt>I586_CPU</tt> for <tt><em>cpu_type</em></tt>. <tag>ident <em>machine_name</em></tag> <p>Next, we have <tt>ident</tt>, which is the identification of the kernel. You should change this from GENERIC to whatever you named your kernel, in this example, MYKERNEL. The value you put in <tt>ident</tt> will print when you boot up the kernel, so it is useful to give a kernel a different name if you want to keep it separate from your usual kernel (if you want to build an experimental kernel, for example). Note that, as with <tt>machine</tt> and <tt> cpu</tt>, enclose your kernel's name in quotation marks if it contains any numbers. Since this name is passed to the C compiler as a <tt>-D</tt> switch, do not use names like <tt> DEBUG</tt>, or something that could be confused with another machine or CPU name, like <tt>vax</tt>. <tag>maxusers <em>number</em></tag> <p>This file sets the size of a number of important system tables. This number is supposed to be roughly equal to the number of simultaneous users you expect to have on your machine. However, under normal circumstances, you will want to set <tt>maxusers</tt> to at least four, especially if you are using X Windows or compiling software. The reason is that the most important table set by <tt>maxusers</tt> is the maximum number of processes, which is set to <bf><tt>20 + 16 * maxusers</tt></bf>, so if you set <tt>maxusers</tt> to one, then you can only have 36 simultaneous processes, including the 18 or so that the system starts up at boot time, and the 15 or so you will probably create when you start X Windows. Even a simple task like reading a <tt>man</tt> page will start up nine processes to filter, decompress, and view it. Setting <tt>maxusers</tt> to 4 will allow you to have up to 84 simultaneous processes, which should be enough for anyone. If, however, you see the dreaded ``proc table full'' error when trying to start another program, or are running a server with a large number of simultaneous users (like Walnut Creek CDROM's FTP site), you can always increase this number and rebuild. <quote><em/Note:/ <tt>maxuser</tt> does <em>not</em> limit the number of users which can log into your machine. It simply sets various table sizes to reasonable values considering the maximum number of users you will likely have on your system and how many processes each of them will be running. One keyword which <em>does</em> limit the number of simultaneous <em>remote logins</em> is <ref id="kernelconfig:ptys" name="pseudo-device pty 16">.</quote> <tag>config <em>kernel_name</em> root on <em>root_device</em></tag> <p>This line specifies the location and name of the kernel. Traditionally the kernel is called <tt>vmunix</tt> but in FreeBSD, it is aptly named <tt>kernel</tt>. You should always use <tt>kernel</tt> for <em>kernel_name</em> because changing it will render numerous system utilities inoperative. The second part of the line specifies the disk and partition where the root filesystem and kernel can be found. Typically this will be <tt>wd0</tt> for systems with non-SCSI drives, or <tt>sd0</tt> for systems with SCSI drives. </descrip> <sect1><heading>General Options</heading> <p>These lines provide kernel support for various filesystems and other options. <descrip> <label id="kernelconfig:mathemu"> <tag>options MATH_EMULATE</tag> <p>This line allows the kernel to simulate a math co-processor if your computer does not have one (386 or 486SX). If you have a Pentium, a 486DX, or a 386 or 486SX with a separate 387 or 487 chip, you can comment this line out. <quote><em>Note:</em> The normal math co-processor emulation routines that come with FreeBSD are <em>not</em> very accurate. If you do not have a math co-processor, and you need the best accuracy, I recommend that you change this option to <tt>GPL_MATH_EMULATE</tt> to use the superior GNU math support, which is not included by default for licensing reasons.</quote> <tag>options ``COMPAT_43''</tag> - <p>Compatibility with BSD 4.3. Leave this in; some + <p>Compatibility with 4.3BSD. Leave this in; some programs will act strangely if you comment this out. <tag>options BOUNCE_BUFFERS</tag> <p>ISA devices and EISA devices operating in an ISA compatibility mode can only perform DMA (Direct Memory Access) to memory below 16 megabytes. This option enables such devices to work in systems with more than 16 megabytes of memory. <tag>options UCONSOLE</tag> <p>Allow users to grab the console, useful for X Windows. For example, you can create a console xterm by typing <tt>xterm -C</tt>, which will display any `write', `talk', and other messages you receive, as well as any console messages sent by the kernel. <tag>options SYSVSHM</tag> <p>This option provides for System V shared memory. The most common use of this is the XSHM extension in X Windows, which many graphics-intensive programs (such as the movie player XAnim, and Linux DOOM) will automatically take advantage of for extra speed. If you use X Windows, you will definitely want to include this. <tag>options SYSVSEM</tag> <p>Support for System V semaphores. Less commonly used but only adds a few hundred bytes to the kernel. <tag>options SYSVMSG</tag> <p>Support for System V messages. Again, only adds a few hundred bytes to the kernel. <quote><em/Note:/ The <tt>ipcs(1)</tt> command will tell will list any processes using using each of these System V facilities.</quote> </descrip> <sect1><heading>Filesystem Options</heading> <p>These options add support for various filesystems. You must include at least one of these to support the device you boot from; typically this will be <tt>FFS</tt> if you boot from a hard drive, or <tt>NFS</tt> if you are booting a diskless workstation from Ethernet. You can include other commonly-used filesystems in the kernel, but feel free to comment out support for filesystems you use less often (perhaps the MS-DOS filesystem?), since they will be dynamically loaded from the Loadable Kernel Module directory <tt>/lkm</tt> the first time you mount a partition of that type. <descrip> <tag>options FFS</tag> <p>The basic hard drive filesystem; leave it in if you boot from the hard disk. <tag>options NFS</tag> <p>Network Filesystem. Unless you plan to mount partitions from a Unix file server over Ethernet, you can comment this out. <tag>options MSDOSFS</tag> <p>MS-DOS Filesystem. Unless you plan to mount a DOS formatted hard drive partition at boot time, you can safely comment this out. It will be automatically loaded the first time you mount a DOS partition, as described above. Also, the excellent <tt>mtools</tt> software (in the ports collection) allows you to access DOS floppies without having to mount and unmount them (and does not require MSDOSFS at all). <tag>options ``CD9660''</tag> <p>ISO 9660 filesystem for CD-ROMs. Comment it out if you do not have a CD-ROM drive or only mount data CD's occasionally (since it will be dynamically loaded the first time you mount a data CD). Audio CD's do not need this filesystem. <tag>options PROCFS</tag> <p>Process filesystem. This is a pretend filesystem mounted on /proc which allows programs like <tt>ps(1)</tt> to give you more information on what processes are running. <tag>options MFS</tag> <p>Memory-mapped file system. This is basically a RAM disk for fast storage of temporary files, useful if you have a lot of swap space that you want to take advantage of. A perfect place to mount an MFS partition is on the <tt>/tmp</tt> directory, since many programs store temporary data here. To mount an MFS RAM disk on <tt>/tmp</tt>, add the following line to <tt>/etc/fstab</tt> and then reboot or type <tt>mount /tmp</tt>: <tscreen><verb> /dev/wd1s2b /tmp mfs rw 0 0 </verb></tscreen> <quote><em/Note:/ Replace the <tt>/dev/wd1s2b</tt> with the name of your swap partition, which will be listed in your <tt>/etc/fstab</tt> as follows: <tscreen><verb> /dev/wd1s2b none swap sw 0 0 </verb></tscreen> </quote> <quote><em/Note:/ <!-- MFS is currently a bit limited (for example, I noticed that two programs ca not access the <tt>/tmp</tt> device simultaneously). As such, you may want to avoid it for now. --> Also, the <tt>MFS</tt> filesystem can <em>not</em> be dynamically loaded, so you <em>must</em> compile it into your kernel if you want to experiment with it.</quote> <tag>options QUOTA</tag> <p>Enable disk quotas. If you have a public access system, and do not want users to be able to overflow the <tt>/home</tt> partition, you can establish disk quotas for each user. This code is a little buggy, so do not enable it unless you have to. View the manual page for <tt>quota(1)</tt> to learn more about disk quotas. </descrip> <sect1><heading>Basic Controllers and Devices</heading> <p>These sections describe the basic disk, tape, and CD-ROM controllers supported by FreeBSD. There are separate sections for <ref id="kernelconfig:scsi" name="SCSI"> controllers and <ref id="kernelconfig:network" name="network"> cards. <descrip> <tag>controller isa0</tag> <p>All PC's supported by FreeBSD have one of these. If you have an IBM PS/2 (Micro Channel Architecture), then you cannot run FreeBSD at this time. <tag>controller pci0</tag> <p>Include this if you have a PCI motherboard. This enables auto-detection of PCI cards and gatewaying from the PCI to the ISA bus. <tag>controller fdc0</tag> <p>Floppy drive controller: <tt>fd0</tt> is the ``A:'' floppy drive, and <tt>fd1</tt> is the ``B:'' drive. <tt>ft0</tt> is a QIC-80 tape drive attached to the floppy controller. Comment out any lines corresponding to devices you do not have. <quote><em/Note:/ QIC-80 tape support requires a separate filter program called <tt>ft(8)</tt>, see the manual page for details.</quote> <tag>controller wdc0</tag> <p>This is the primary IDE controller. <tt>wd0</tt> and <tt>wd1</tt> are the master and slave hard drive, respectively. <tt>wdc1</tt> is a secondary IDE controller where you might have a third or fourth hard drive, or an IDE CD-ROM. Comment out the lines which do not apply (if you have a SCSI hard drive, you will probably want to comment out all six lines, for example). <tag>controller wcd0<label id="kernelconfig:atapi"></tag> <p>This device provides IDE CD-ROM support. Be sure to leave <tt>wdc1</tt> uncommented if your CD-ROM is on its own controller card. To use this, you must also include the line <tt>options ATAPI</tt>. <tag>device npx0 at isa? port ``IO_NPX'' irq 13 vector npxintr</tag> <p><tt>npx0</tt> is the interface to the floating point math unit in FreeBSD, either the hardware co-processor or the software math emulator. It is <em/NOT/ optional. <tag>device wt0 at isa? port 0x300 bio irq 5 drq 1 vector wtintr</tag> <p>Wangtek and Archive QIC-02/QIC-36 tape drive support <tag>Proprietary CD-ROM support</tag> <p>The following drivers are for the so-called <em>proprietary</em> CD-ROM drives. These drives have their own controller card or might plug into a sound card such as the SoundBlaster 16. They are <em>not</em> IDE or SCSI. Most older single-speed and double-speed CD-ROMs use these interfaces, while newer quad-speeds are likely to be <ref id="kernelconfig:atapi" name="IDE"> or <ref id="kernelconfig:scsi" name="SCSI">. <descrip> <tag>device mcd0 at isa? port 0x300 bio irq 10 vector mcdintr</tag> <p>Mitsumi CD-ROM (LU002, LU005, FX001D). <tag>device scd0 at isa? port 0x230 bio</tag> <p>Sony CD-ROM (CDU31, CDU33A). <tag>controller matcd0 at isa? port ? bio</tag> <p>Matsushita/Panasonic CD-ROM (sold by Creative Labs for SoundBlaster). </descrip> </descrip> <sect1><heading>SCSI Device Support<label id="kernelconfig:scsi"></heading> <p>This section describes the various SCSI controllers and devices supported by FreeBSD. <descrip> <tag>SCSI Controllers</tag> <p>The next ten or so lines include support for different kinds of SCSI controllers. Comment out all except for the one(s) you have: <descrip> <tag>controller bt0 at isa? port ``IO_BT0'' bio irq ? vector btintr</tag> <p>Most Buslogic controllers <tag>controller uha0 at isa? port ``IO_UHA0'' bio irq ? drq 5 vector uhaintr</tag> <p>UltraStor 14F and 34F <tag>controller ahc0</tag> <p>Adaptec 274x/284x/294x <tag>controller ahb0 at isa? bio irq ? vector ahbintr</tag> <p>Adaptec 174x <tag>controller aha0 at isa? port ``IO_AHA0'' bio irq ? drq 5 vector ahaintr</tag> <p>Adaptec 154x <tag>controller aic0 at isa? port 0x340 bio irq 11 vector aicintr </tag> <p>Adaptec 152x and sound cards using Adaptec AIC-6360 (slow!) <tag>controller nca0 at isa? port 0x1f88 bio irq 10 vector ncaintr </tag> <p>ProAudioSpectrum cards using NCR 5380 or Trantor T130 <tag>controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr</tag> <p>Seagate ST01/02 8 bit controller (slow!) <tag>controller wds0 at isa? port 0x350 bio irq 15 drq 6 vector wdsintr</tag> <p>Western Digital WD7000 controller <tag>controller ncr0</tag> <p>NCR 53C810, 53C815, 53C825, 53C860, 53C875 PCI SCSI controller </descrip> <tag>options ``SCSI_DELAY=15''</tag> <p>This causes the kernel to pause 15 seconds before probing each SCSI device in your system. If you only have IDE hard drives, you can ignore this, otherwise you will probably want to lower this number, perhaps to 5 seconds, to speed up booting. Of course if you do this, and FreeBSD has trouble recognizing your SCSI devices, you will have to raise it back up. <tag>controller scbus0</tag> <p>If you have any SCSI controllers, this line provides generic SCSI support. If you do not have SCSI, you can comment this, and the following three lines, out. <tag>device sd0</tag> <p>Support for SCSI hard drives. <tag>device st0</tag> <p>Support for SCSI tape drives. <tag>device cd0</tag> <p>Support for SCSI CD-ROM drives. <p>Note that the number <bf>0</bf> in the above entries is slightly misleading: all these devices are automatically configured as they are found, regardless of how many of them are hooked up to the SCSI bus(es), and which target IDs they have. If you want to ``wire down'' specific target IDs to particular devices, refer to the appropriate section of the LINT kernel config file. </descrip> <sect1><heading>Console, Bus Mouse, and X Server Support</heading> <p>You must choose one of these two console types, and, if you plan to use X Windows, enable the XSERVER option and optionally, a bus mouse or PS/2 mouse device. <descrip> <tag>device sc0 at isa? port ``IO_KBD' tty irq 1 vector scintr</tag> <p><tt>sc0</tt> is the default console driver, which resembles an SCO console. Since most full-screen programs access the console through a terminal database library like <em>termcap</em>, it should not matter much whether you use this or <tt>vt0</tt>, the VT220 compatible console driver. When you log in, set your TERM variable to ``scoansi'' if full-screen programs have trouble running under this console. <tag>device vt0 at isa? port ``IO_KBD'' tty irq 1 vector pcrint</tag> <p>This is a VT220-compatible console driver, backwards compatible to VT100/102. It works well on some laptops which have hardware incompatibilities with <tt>sc0</tt>. Also, set your TERM variable to ``vt100'' or ``vt220'' when you log in. This driver might also prove useful when connecting to a large number of different machines over the network, where the <em>termcap</em> or <em>terminfo</em> entries for the <tt>sc0</tt> device are often not available -- ``vt100'' should be available on virtually any platform. <descrip> <tag>options ``PCVT_FREEBSD=210''</tag> <p>Required with the <tt>vt0</tt> console driver. <tag>options XSERVER</tag> <p>This includes code required to run the <tt>XFree86</tt> X Window Server. </descrip> <tag>device mse0 at isa? port 0x23c tty irq 5 vector ms</tag> <p>Use this device if you have a Logitech or ATI InPort bus mouse card. <quote><em/Note:/ If you have a serial mouse, ignore these two lines, and instead, make sure the appropriate <ref id="kernelconfig:serial" name="serial"> port is enabled (probably COM1).</quote> <tag>device psm0 at isa? port ``IO_KBD'' conflicts tty irq 12 vector psmintr</tag> <p>Use this device if your mouse plugs into the PS/2 mouse port. </descrip> <sect1><heading>Serial and Parallel Ports</heading> <p>Nearly all systems have these. If you are attaching a printer to one of these ports, the <ref id="printing" name="Printing"> section of the handbook is very useful. If you are using modem, <ref id="dialup" name="Dialup access"> provides extensive detail on serial port configuration for use with such devices. <descrip> <tag>device sio0 at isa? port ``IO_COM1'' tty irq 4 vector siointr<label id="kernelconfig:serial"></tag> <p><tt>sio0</tt> through <tt>sio3</tt> are the four serial ports referred to as COM1 through COM4 in the MS-DOS world. Note that if you have an internal modem on COM4 and a serial port at COM2 you will have to change the IRQ of the modem to 2 (for obscure technical reasons IRQ 2 = IRQ 9) in order to access it from FreeBSD. If you have a multiport serial card, check the manual page for <tt>sio(4)</tt> for more information on the proper values for these lines. Some video cards (notably those based on S3 chips) use IO addresses of the form <tt>0x*2e8</tt>, and since many cheap serial cards do not fully decode the 16-bit IO address space, they clash with these cards, making the COM4 port practically unavailable. Each serial port is required to have a unique IRQ (unless you are using one of the multiport cards where shared interrupts are supported), so the default IRQs for COM3 and COM4 cannot be used. <tag>device lpt0 at isa? port? tty irq 7 vector lptintr</tag> <p><tt>lpt0</tt> through <tt>lpt2</tt> are the three printer ports you could conceivably have. Most people just have one, though, so feel free to comment out the other two lines if you do not have them. </descrip> <sect1><heading>Networking<label id="kernelconfig:network"></heading> <p>FreeBSD, as with Unix in general, places a <em>big</em> emphasis on networking. Therefore, even if you do not have an Ethernet card, pay attention to the mandatory options and the dial-up networking support. <descrip> <tag>options INET</tag> Networking support. Leave it in even if you do not plan to be connected to a network. Most programs require at least loopback networking (i.e. making network connections within your PC) so this is essentially mandatory. <tag>Ethernet cards</tag> <p>The next lines enable support for various Ethernet cards. If you do not have a network card, you can comment out all of these lines. Otherwise, you will want to leave in support for your particular Ethernet card(s): <descrip> <tag>device de0</tag> <p>Ethernet adapters based on Digital Equipment DC21040, DC21041 or DC21140 chips <tag>device fxp0</tag> <p>Intel EtherExpress Pro/100B <tag>device vx0</tag> <p>3Com 3C590 and 3C595 (buggy) <tag>device cx0 at isa? port 0x240 net irq 15 drq 7 vector cxintr</tag> <p>Cronyx/Sigma multiport sync/async (with Cisco or PPP framing) <tag>device ed0 at isa? port 0x280 net irq 5 iomem 0xd8000 vector edintr</tag> <p>Western Digital and SMC 80xx and 8216; Novell NE1000 and NE2000; 3Com 3C503 <tag>device el0 at isa? port 0x300 net irq 9 vector elintr</tag> <p>3Com 3C501 (slow!) <tag>device eg0 at isa? port 0x310 net irq 5 vector egintr</tag> <p>3Com 3C505 <tag>device ep0 at isa? port 0x300 net irq 10 vector epintr</tag> <p>3Com 3C509 (buggy) <tag>device fe0 at isa? port 0x240 net irq ? vector feintr</tag> <p>Fujitsu MB86960A/MB86965A Ethernet <tag>device fea0 at isa? net irq ? vector feaintr</tag> <p>DEC DEFEA EISA FDDI adapter <tag>device ie0 at isa? port 0x360 net irq 7 iomem 0xd0000 vector ieintr</tag> <p>AT&T StarLAN 10 and EN100; 3Com 3C507; unknown NI5210 <tag>device ix0 at isa? port 0x300 net irq 10 iomem 0xd0000 iosiz 32768 vector ixintr</tag> <p>Intel EtherExpress 16 <tag>device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 vector le_intr</tag> <p>Digital Equipment EtherWorks 2 and EtherWorks 3 (DEPCA, DE100, DE101, DE200, DE201, DE202, DE203, DE204, DE205, DE422) <tag>device lnc0 at isa? port 0x300 net irq 10 drq 0 vector lncintr</tag> <p>Lance/PCnet cards (Isolan, Novell NE2100, NE32-VL) <tag>device ze0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector zeintr</tag> <p>IBM/National Semiconductor PCMCIA ethernet controller. <tag>device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zpintr</tag> <p>3Com PCMCIA Etherlink III </descrip> <quote><em/Note:/ With certain cards (notably the NE2000) you will have to change the port and/or IRQ since there is no ``standard'' location for these cards.</quote> <tag>pseudo-device loop</tag> <p><tt>loop</tt> is the generic loopback device for TCP/IP. If you telnet or FTP to <em>localhost</em> (a.k.a. <tt>127.0.0.1</tt>) it will come back at you through this pseudo-device. Mandatory. <tag>pseudo-device ether</tag> <p><tt>ether</tt> is only needed if you have an Ethernet card and includes generic Ethernet protocol code. <tag>pseudo-device sl <em>number</em></tag> <p><tt>sl</tt> is for SLIP (Serial Line Internet Protocol) support. This has been almost entirely supplanted by PPP, which is easier to set up, better suited for modem-to-modem connections, as well as more powerful. The <em>number</em> after <tt>sl</tt> specifies how many simultaneous SLIP sessions to support. This handbook has more information on setting up a SLIP <ref id="slipc" name="client"> or <ref id="slips" name="server">. <tag>pseudo-device ppp <em>number</em></tag> <p><tt>ppp</tt> is for kernel-mode PPP (Point-to-Point Protocol) support for dial-up Internet connections. There is also version of PPP implemented as a user application that uses the <tt>tun</tt> and offers more flexibility and features such as demand dialing. If you still want to use this PPP driver, read the <ref id="ppp" name="kernel-mode PPP"> section of the handbook. As with the <tt>sl</tt> device, <em>number</em> specifies how many simultaneous PPP connections to support. <tag>pseudo-device tun <em>number</em></tag> <p><tt>tun</tt> is used by the user-mode PPP software. This program is easy to set up and very fast. It also has special features such as automatic dial-on-demand. The number after <tt>tun</tt> specifies the number of simultaneous PPP sessions to support. See the <ref id="userppp" name="user-mode PPP"> section of the handbook for more information. <tag>pseudo-device bpfilter <em>number</em></tag> <p>Berkeley packet filter. This pseudo-device allows network interfaces to be placed in promiscuous mode, capturing every packet on a broadcast network (e.g. an ethernet). These packets can be captured to disk and/or examined with the <tt>tcpdump(1)</tt> program. Note that implementation of this capability can seriously compromise your overall network security. The <em>number</em> after bpfilter is the number of interfaces that can be examined simultaneously. Optional, not recommended except for those who are fully aware of the potential pitfalls. Not all network cards support this capability. </descrip> <sect1><heading>Sound cards</heading> <p>This is the first section containing lines that are not in the GENERIC kernel. To include sound card support, you will have to copy the appropriate lines from the LINT kernel (which contains support for <em>every</em> device) as follows: <descrip> <tag>controller snd0</tag> <p>Generic sound driver code. Required for all of the following sound cards except <tt>pca</tt>. <tag>device pas0 at isa? port 0x388 irq 10 drq 6 vector pasintr</tag> <p>ProAudioSpectrum digital audio and MIDI. <tag>device sb0 at isa? port 0x220 irq 7 conflicts drq 1 vector sbintr</tag> <p>SoundBlaster digital audio. <quote><em/Note:/ If your SoundBlaster is on a different IRQ (such as 5), change <tt>irq 7</tt> to, for example, <tt>irq 5</tt> and remove the <tt>conflicts</tt> keyword. Also, you must add the line: <tt>options ``SBC_IRQ=5''</tt></quote> <tag>device sbxvi0 at isa? drq 5</tag> <p>SoundBlaster 16 digital 16-bit audio. <quote><em/Note:/ If your SB16 is on a different 16-bit DMA channel (such as 6 or 7), change the <tt>drq 5</tt> keyword appropriately, and then add the line: <tt>options "SB16_DMA=6"</tt></quote> <tag>device sbmidi0 at isa? port 0x330</tag> <p>SoundBlaster 16 MIDI interface. If you have a SoundBlaster 16, you must include this line, or the kernel will not compile. <tag>device gus0 at isa? port 0x220 irq 10 drq 1 vector gusintr</tag> <p>Gravis Ultrasound. <tag>device mss0 at isa? port 0x530 irq 10 drq 1 vector adintr</tag> <p>Microsoft Sound System. <tag>device opl0 at isa? port 0x388 conflicts</tag> <p>AdLib FM-synthesis audio. Include this line for AdLib, SoundBlaster, and ProAudioSpectrum users, if you want to play MIDI songs with a program such as <tt>playmidi</tt> (in the ports collection). <tag>device mpu0 at isa? port 0x330 irq 6 drq 0</tag> <p>Roland MPU-401 stand-alone card. <tag>device uart0 at isa? port 0x330 irq 5 vector ``m6850intr''</tag> <p>Stand-alone 6850 UART for MIDI. <tag>device pca0 at isa? port ``IO_TIMER1'' tty<label id="kernelconfig:pcaudio"></tag> <p>Digital audio through PC speaker. This is going to be very poor sound quality and quite CPU-intensive, so you have been warned (but it does not require a sound card). </descrip> <quote><em/Note:/ There is some additional documentation in <tt>/usr/src/sys/i386/isa/sound/sound.doc</tt>. Also, if you add any of these devices, be sure to create the sound <ref id="kernelconfig:nodes" name="device nodes">.</quote> <sect1><heading>Pseudo-devices</heading> <p>Pseudo-device drivers are parts of the kernel that act like device drivers but do not correspond to any actual hardware in the machine. The <ref id="kernelconfig:network" name="network-related"> pseudo-devices are in that section, while the remainder are here. <descrip> <tag>pseudo-device gzip</tag> <p><tt>gzip</tt> allows you to run FreeBSD programs that have been compressed with <tt>gzip</tt>. The programs in <tt>/stand</tt> are compressed so it is a good idea to have this option in your kernel.</p> <tag>pseudo-device log</tag> <p><tt>log</tt> is used for logging of kernel error messages. Mandatory. <tag>pseudo-device pty <em>number</em><label id="kernelconfig:ptys"></tag> <p><tt>pty</tt> is a ``pseudo-terminal'' or simulated login port. It is used by incoming <bf>telnet</bf> and <bf>rlogin</bf> sessions, xterm, and some other applications such as emacs. The <em>number</em> indicates the number of <tt>pty</tt>s to create. If you need more than GENERIC default of 16 simultaneous xterm windows and/or remote logins, be sure to increase this number accordingly, up to a maximum of 64. <tag>pseudo-device snp <em>number</em></tag> <p>Snoop device. This pseudo-device allows one terminal session to watch another using the <tt>watch(8)</tt> command. Note that implementation of this capability has important security and privacy implications. The <em>number</em> after snp is the total number of simultaneous snoop sessions. Optional. <tag>pseudo-device vn</tag> <p>Vnode driver. Allows a file to be treated as a device after being set up with the <tt>vnconfig(8)</tt> command. This driver can be useful for manipulating floppy disk images and using a file as a swap device (e.g. an MS Windows swap file). Optional. <tag>pseudo-device ccd <em>number</em></tag> <p>Concatenated disks. This pseudo-device allows you to concatenate multiple disk partitions into one large ``meta''-disk. The <em>number</em> after ccd is the total number of concatenated disks (not total number of disks that can be concatenated) that can be created. (See <tt>ccd(4)</tt> and <tt>ccdconfig(8)</tt> man pages for more details.) Optional. </descrip> <sect1><heading>Joystick, PC Speaker, Miscellaneous</heading> <p>This section describes some miscellaneous hardware devices supported by FreeBSD. Note that none of these lines are included in the GENERIC kernel, you will have to copy them from this handbook or the LINT kernel (which contains support for <em>every</em> device): <descrip> <tag>device joy0 at isa? port ``IO_GAME''</tag> <p>PC joystick device. <tag>pseudo-device speaker</tag> <p>Supports IBM BASIC-style noises through the PC speaker. Some fun programs which use this are <tt>/usr/sbin/spkrtest</tt>, which is a shell script that plays some simple songs, and <tt>/usr/games/piano</tt> which lets you play songs using the keyboard as a simple piano (this file only exists if you have installed the <em>games</em> package). Also, the excellent text role-playing game NetHack (in the ports collection) can be configured to use this device to play songs when you play musical instruments in the game. <p>See also the <ref id="kernelconfig:pcaudio" name="pca0"> device. </descrip> <sect><heading>Making Device Nodes<label id="kernelconfig:nodes"></heading> <p>Almost every device in the kernel has a corresponding ``node'' entry in the <tt>/dev</tt> directory. These nodes look like regular files, but are actually special entries into the kernel which programs use to access the device. The shell script <tt>/dev/MAKEDEV</tt>, which is executed when you first install the operating system, creates nearly all of the device nodes supported. However, it does not create <em>all</em> of them, so when you add support for a new device, it pays to make sure that the appropriate entries are in this directory, and if not, add them. Here is a simple example: Suppose you add the IDE CD-ROM support to the kernel. The line to add is: <tscreen><verb> controller wcd0 </verb></tscreen> This means that you should look for some entries that start with <tt>wcd0</tt> in the <tt>/dev</tt> directory, possibly followed by a letter, such as `c', or preceded by the letter 'r', which means a `raw' device. It turns out that those files are not there, so I must change to the <tt>/dev</tt> directory and type: <tscreen><verb> # sh MAKEDEV wcd0 </verb></tscreen> When this script finishes, you will find that there are now <tt>wcd0c</tt> and <tt>rwcd0c</tt> entries in <tt>/dev</tt> so you know that it executed correctly. For sound cards, the command: <tscreen><verb> # sh MAKEDEV snd0 </verb></tscreen> creates the appropriate entries. Follow this simple procedure for any other non-GENERIC devices which do not have entries. <quote><em/Note:/ All SCSI controllers use the same set of <tt>/dev</tt> entries, so you do not need to create these. Also, network cards and SLIP/PPP pseudo-devices do not have entries in <tt>/dev</tt> at all, so you do not have to worry about these either.</quote> <sect><heading>If Something Goes Wrong<label id="kernelconfig:trouble"></heading> <p>There are four categories of trouble that can occur when building a custom kernel. They are: <descrip> <tag>Config command fails</tag> <p>If the <tt>config</tt> command fails when you give it your kernel description, you have probably made a simple error somewhere. Fortunately, <tt>config</tt> will print the line number that it had trouble with, so you can quickly skip to it with <tt>vi</tt>. For example, if you see: <tscreen><verb> config: line 17: syntax error </verb></tscreen> you can skip to the problem in <tt>vi</tt> by typing ``17G'' in command mode. Make sure the keyword is typed correctly, by comparing it to the GENERIC kernel or another reference. <tag>Make command fails</tag> <p>If the <tt>make</tt> command fails, it usually signals an error in your kernel description, but not severe enough for <tt>config</tt> to catch it. Again, look over your configuration, and if you still cannot resolve the problem, send mail to the &a.questions with your kernel configuration, and it should be diagnosed very quickly. <tag>Kernel will not boot<label id="kernelconfig:noboot"></tag> <p>If your new kernel does not boot, or fails to recognize your devices, do not panic! Fortunately, BSD has an excellent mechanism for recovering from incompatible kernels. Simply type the name of the kernel you want to boot from (i.e. ``kernel.old'') at the FreeBSD boot prompt instead of pressing return. When reconfiguring a kernel, it is always a good idea to keep a kernel that is known to work on hand. After booting with a good kernel you can check over your configuration file and try to build it again. One helpful resource is the <tt>/var/log/messages</tt> file which records, among other things, all of the kernel messages from every successful boot. Also, the <tt>dmesg(8)</tt> command will print the kernel messages from the current boot. <quote><em/Note:/ If you are having trouble building a kernel, make sure to keep a GENERIC, or some other kernel that is known to work on hand as a different name that will not get erased on the next build. You cannot rely on <tt>kernel.old</tt> because when installing a new kernel, <tt>kernel.old</tt> is overwritten with the last installed kernel which may be non-functional. Also, as soon as possible, move the working kernel to the proper ``kernel'' location or commands such as <tt>ps(1)</tt> will not work properly. The proper command to ``unlock'' the kernel file that <tt>make</tt> installs (in order to move another kernel back permanently) is: <tscreen><verb> # chflags noschg /kernel </verb></tscreen> And, if you want to ``lock'' your new kernel into place, or any file for that matter, so that it cannot be moved or tampered with: <tscreen><verb> # chflags schg /kernel </verb></tscreen> </quote> <tag>Kernel works, but <tt>ps</tt> does not work any more!</tag> <p>If you have installed a different version of the kernel from the one that the system utilities have been built with, for example, an experimental ``2.2.0'' kernel on a 2.1.0-RELEASE system, many system-status commands like <tt>ps(1)</tt> and <tt>vmstat(8)</tt> will not work any more. You must recompile the <tt>libkvm</tt> library as well as these utilities. This is one reason it is not normally a good idea to use a different version of the kernel from the rest of the operating system. </descrip> diff --git a/handbook/linuxemu.sgml b/handbook/linuxemu.sgml index 9e1454f7d2..b4ec73d386 100644 --- a/handbook/linuxemu.sgml +++ b/handbook/linuxemu.sgml @@ -1,700 +1,700 @@ -<!-- $Id: linuxemu.sgml,v 1.9 1996-08-12 11:48:47 peter Exp $ --> +<!-- $Id: linuxemu.sgml,v 1.10 1996-08-21 07:28:52 asami Exp $ --> <!-- The FreeBSD Documentation Project --> <chapt><heading>Linux Emulation<label id="linuxemu"></heading> <p><em>Contributed by &a.brian and &a.rich;</em> <sect><heading>How to install the Linux emulator</heading> <p>Linux emulation in FreeBSD has reached a point where it is possible to run a large fraction of Linux binaries in both a.out and ELF format. The linux emulation in the -STABLE branch is capable of running Linux DOOM and Mathematica; the version present in FreeBSD-CURRENT is vastly more capable and runs all these as well as Quake, Abuse, IDL, netrek for Linux and a whole host of other programs. There are some Linux-specific operating system features that are not supported on FreeBSD. Linux binaries will not work on FreeBSD if they use the Linux /proc filesystem (which is different from the optional FreeBSD /proc filesystem) or i386-specific calls, such as enabling virtual 8086 mode. <p>To tell whether your kernel is configured for Linux compatibility simply run any Linux binary. If it prints the error message <tscreen> <verb> linux-executable: Exec format error. Wrong Architecture. </verb> </tscreen> then you do not have linux compatibility support and you need to configure and install a new kernel. Depending on which version of FreeBSD you are running, how you get Linux-emulation up will vary slightly: <sect1><heading>Installing Linux Emulation in 2.1-STABLE</heading> <p>The GENERIC kernel in 2.1-stable is not configured for linux compatibility so you you must reconfigure your kernel for it. There are two ways to do this: 1. linking the emulator statically in the kernel itself and 2. configuring your kernel to dynamically load the linux loadable kernel module (LKM). <p>To enable the emulator, add the following to your configuration file (c.f. /sys/i386/conf/LINT): <tscreen> <verb> options COMPAT_LINUX </verb> </tscreen> If you want to run doom or other applications that need shared memory also add the following. <tscreen> <verb> options SYSVSHM </verb> </tscreen> -The linux system calls require 4.3 BSD system call compatibility. So +The linux system calls require 4.3BSD system call compatibility. So make sure you have the following. <tscreen> <verb> options "COMPAT_43" </verb> </tscreen> If you prefer to statically link the emulator in the kernel rather than use the loadable kernel module (LKM), then add <tscreen> <verb> options LINUX </verb> </tscreen> Then run config and install the new kernel as described in the <ref id="kernelconfig" name="kernel configuration"> section. If you decide to use the LKM you must also install the loadable module. A mismatch of versions between the kernel and loadable module can cause the kernel to crash, so the safest thing to do is to reinstall the LKM when you install the kernel. <tscreen> <verb> % cd /usr/src/lkm/linux % make all install </verb> </tscreen> Once you have installed the kernel and the LKM, you can invoke `linux' as root to load the LKM. <tscreen> <verb> % linux Linux emulator installed Module loaded as ID 0 % </verb> </tscreen> To see whether the LKM is loaded, run `modstat'. <tscreen> <verb> % modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 3 f0baf000 0018 f0bb4000 1 linux_emulator % </verb> </tscreen> You can cause the LKM to be loaded when the system boots in either of two ways. On FreeBSD-CURRENT and FreeBSD-STABLE enable it in /etc/sysconfig <tscreen> <verb> linux=YES </verb> </tscreen> by changing it from NO to YES. FreeBSD 2.1 RELEASE and earlier do not have such a line and on those you will need to edit /etc/rc.local to add the following line. <tscreen> <verb> linux </verb> </tscreen> <sect1><heading>Installing Linux Emulation in 2.2-CURRENT</heading> <p>In -current it is no longer necessary to specify ``options LINUX'' or ``options COMPAT_LINUX''. Linux emulation is done with an LKM (``Loadable Kernel Module'') so it can be installed on the fly without having to reboot. You will need the following things in your startup files, however: <enum> <item> In /etc/sysconfig, you need the following line: <tscreen> <verb> linux=YES </verb> </tscreen> <item> This, in turn, triggers the following action in /etc/rc.i386: <tscreen> <verb> # Start the Linux binary emulation if requested. if [ "X${linux}" = X"YES" ]; then echo -n ' '; linux # XXX BOGUS - Linux script shouldn't make any output on success fi </verb> </tscreen> </enum> <p>If you want to verify it is running, modstat will do that: <tscreen> <verb> % modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 4 f09e6000 001c f09ec010 1 linux_mod % </verb> </tscreen> However, there have been reports that this fails on some FreeBSD-current systems. If for some reason you cannot load the linux LKM, then statically link the emulator in the kernel by adding <tscreen> <verb> options LINUX </verb> </tscreen> to your kernel config file. Then run config and install the new kernel as described in the <ref id="kernelconfig" name="kernel configuration"> section. <sect1><heading>Installing Linux Runtime Libraries</heading> <sect2><heading>Installing using the linux_lib port</heading> <p>Most linux applications use shared libraries, so you are still not done until you install the shared libraries. It is possible to do this by hand, however, it is vastly simpler to just grab the linux_lib port: <tscreen> <verb> % cd /usr/ports-current/emulators/linux_lib % make all install </verb> </tscreen> and you should have a working linux emulator. Legend (and the mail archives :-) seems to hold that Linux emulation works best with linux binaries linked against the ZMAGIC libraries; QMAGIC libraries (such as those used in Slackware V2.0) may tend to give the Linuxulator heartburn. As of this writing (March 1996) ELF emulation is still in the formulative stages but seems to work pretty well. Also, expect some programs to complain about incorrect minor versions. In general this does not seem to be a problem. <sect2><heading>Installing libraries manually</heading> <p>If you don't have the ``ports'' distribution, you can install the libraries by hand instead. You will need the Linux shared libraries that the program depends on and the runtime linker. Also, you will need to create a "shadow root" directory, /compat/linux, for Linux libraries on your FreeBSD system. Any shared libraries opened by Linux programs run under FreeBSD will look in this tree first. So, if a Linux program loads, for example, /lib/libc.so, FreeBSD will first try to open /compat/linux/lib/libc.so, and if that does not exist then it will try /lib/libc.so. Shared libraries should be installed in the shadow tree /compat/linux/lib rather than the paths that the Linux ld.so reports. FreeBSD-current works slightly differently with respect to /compat/linux. On -current, all files, not just libraries, are searched for from the ``shadow root'' /compat/linux. Generally, you will need to look for the shared libraries that Linux binaries depend on only the first few times that you install a Linux program on your FreeBSD system. After a while, you will have a sufficient set of Linux shared libraries on your system to be able to run newly imported Linux binaries without any extra work. <sect2><heading>How to install additional shared libraries</heading> <p>What if you install the linux_lib port and your application still complains about missing shared libraries? How do you know which shared libraries Linux binaries need, and where to get them? Basically, there are 2 possibilities (when following these instructions: you will need to be root on your FreeBSD system to do the necessary installation steps). <p>If you have access to a Linux system, see what shared libraries it needs, and copy them to your FreeBSD system. Example: you have just ftp'ed the Linux binary of Doom. Put it on the Linux system you have access to, and check which shared libraries it needs by running `ldd linuxxdoom': <tscreen> <verb> % ldd linuxxdoom libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0 libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0 libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29 </verb> </tscreen> <p>You would need go get all the files from the last column, and put them under /compat/linux, with the names in the first column as symbolic links pointing to them. This means you eventually have these files on your FreeBSD system: <tscreen> <verb> /compat/linux/usr/X11/lib/libXt.so.3.1.0 /compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0 /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29 </verb> </tscreen> <p>Note that if you already have a Linux shared library with a matching major revision number to the first column of the 'ldd' output, you will not need to copy the file named in the last column to your system, the one you already have should work. It is advisable to copy the shared library anyway if it is a newer version, though. You can remove the old one, as long as you make the symbolic link point to the new one. So, if you have these libraries on your system: <tscreen> <verb> /compat/linux/lib/libc.so.4.6.27 /compat/linux/lib/libc.so.4 -> libc.so.4.6.27 </verb> </tscreen> and you find a new binary that claims to require a later version according to the output of ldd: <tscreen> <verb> libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29 </verb> </tscreen> If it is only one or two versions out of date in the in the trailing digit then do not worry about copying /lib/libc.so.4.6.29 too, because the program should work fine with the slightly older version. However, if you like you can decide to replace the libc.so anyway, and that should leave you with: <tscreen> <verb> /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29 </verb> </tscreen> <p>Please note that the symbolic link mechanism is <em>only</em> needed for Linux binaries, the FreeBSD runtime linker takes care of looking for matching major revision numbers itself, you do not need to worry about that. <sect2><heading>Configuring the ld.so -- for FreeBSD-current only</heading> <p>This section applies only to FreeBSD-current only. Those running FreeBSD-stable should skip this section. <p>Finally, if you run FreeBSD-current you must make sure that you have the Linux runtime linker and its config files on your system. You should copy these files from the Linux system to their appropriate place on your FreeBSD system (to the /compat/linux tree): <tscreen> <verb> /compat/linux/lib/ld.so /compat/linux/etc/ld.so.config </verb> </tscreen> <p>If you do not have access to a Linux system, you should get the extra files you need from various ftp sites. Information on where to look for the various files is appended below. For now, let us assume you know where to get the files. <p> Retrieve the following files (all from the same ftp site to avoid any version mismatches), and install them under /compat/linux (i.e. /foo/bar is installed as /compat/linux/foo/bar): <tscreen> <verb> /sbin/ldconfig /usr/bin/ldd /lib/libc.so.x.y.z /lib/ld.so </verb> </tscreen> <p>ldconfig and ldd do not necessarily need to be under /compat/linux, you can install them elsewhere in the system too. Just make sure they do not conflict with their FreeBSD counterparts. A good idea would be to install them in /usr/local/bin as ldconfig-linux and ldd-linux. <p> Create the file /compat/linux/etc/ld.so.conf, containing the directories in which the Linux runtime linker should look for shared libs. It is a plain text file, containing a directory name on each line. /lib and /usr/lib are standard, you could add the following: <tscreen> <verb> /usr/X11/lib /usr/local/lib </verb> </tscreen> <p>When a linux binary opens a library such as /lib/libc.so the emulator maps the name to /compat/linux/lib/libc.so internally. All linux libraries should be installed under /compat/linux (e.g. /compat/linux/lib/libc.so, /compat/linux/usr/X11/lib/libX11.so, etc.) in order for the emulator to find them. <p>Those running FreeBSD-current should run the Linux ldconfig program. <tscreen> <verb> % cd /compat/linux/lib % /compat/linux/sbin/ldconfig </verb> </tscreen> <p>Ldconfig is statically linked, so it does not need any shared libraries to run. It creates the file /compat/linux/etc/ld.so.cache which contains the names of all the shared libraries. It should rerun to recreate this file whenever you install additional shared libraries. On FreeBSD-stable do not install /compat/linux/etc/ld.so.cache or run ldconfig becuase in FreeBSD-stable the syscalls are implemented differently and ldconfig is not needed or used. <p>You should now be set up for Linux binaries which only need a shared libc. You can test this by running the Linux ldd on itself. Suppose that you have it installed as ldd-linux, it should produce something like: <tscreen> <verb> % ldd-linux `which ldd-linux` libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29 </verb> </tscreen> <p>This being done, you are ready to install new Linux binaries. Whenever you install a new Linux program, you should check if it needs shared libraries, and if so, whether you have them installed in the /compat/linux tree. To do this, you run the Linux version ldd on the new program, and watch its output. ldd (see also the manual page for ldd(1)) will print a list of shared libraries that the program depends on, in the form majorname (jumpversion) => fullname. <p>If it prints "not found" instead of fullname it means that you need an extra library. Which library this is, is shown in majorname, which will be of the form libXXXX.so.N You will need to find a libXXXX.so.N.mm on a Linux ftp site, and install it on your system. The XXXX (name) and N (major revision number) should match; the minor number(s) mm are less important, though it is advised to take the most recent version. <sect1><heading>Configuring the host name resolver</heading> <p>If DNS does not work or you get the messages <tscreen> <verb> resolv+: "bind" is an invalid keyword resolv+: "hosts" is an invalid keyword </verb> </tscreen> then you need to configure a /compat/linux/etc/host.conf file containing: <tscreen> <verb> order hosts, bind multi on </verb> </tscreen> where the order here specifies that /etc/hosts is searched first and DNS is searched second. When /compat/linux/etc/host.conf is not installed linux applications find FreeBSD's /etc/host.conf and complain about the incompatible FreeBSD syntax. You should remove `bind,' if you have not configured a name-server using the /etc/resolv.conf file. <p>Lastly, those who run FreeBSD-stable need to set an the RESOLV_HOST_CONF environment variable so that applications will know how to search the host tables. If you run FreeBSD-current you can skip this. For the /bin/csh shell use: <tscreen> <verb> setenv RESOLV_HOST_CONF /compat/linux/etc/host.conf </verb> </tscreen> For /bin/sh use: <tscreen> <verb> RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF </verb> </tscreen> <sect1><heading>Finding the necessary files</heading> <p>Note: the information below is valid as of the time this document was written, but certain details such as names of ftp sites, directories and distribution names may have changed by the time you read this. <p>Linux is distributed by several groups that make their own set of binaries that they distribute. Each distribution has its own name, like ``Slackware'' or ``Yggdrasil''. The distributions are available on a lot of ftp sites. Sometimes the files are unpacked, and you can get the individual files you need, but mostly they are stored in distribution sets, usually consisting of subdirectories with gzipped tar files in them. The primary ftp sites for the distributions are: <verb> sunsite.unc.edu:/pub/Linux/distributions tsx-11.mit.edu:/pub/linux/distributions </verb> <p> Some European mirrors: <verb> ftp.luth.se:/pub/linux/distributions ftp.demon.co.uk:/pub/linux/distributions src.doc.ic.ac.uk:/packages/linux/distributions </verb> <p>For simplicity, let us concentrate on Slackware here. This distribution consists of a number of subdirectories, containing separate packages. Normally, they are controlled by an install program, but you can retrieve files "by hand" too. First of all, you will need to look in the "contents" subdir of the distribution. You will find a lot of small text files here describing the contents of the separate packages. The fastest way to look something up is to retrieve all the files in the contents subdirectory, and grep through them for the file you need. Here is an example of a list of files that you might need, and in which contents-file you will find it by grepping through them: <tabular ca=ll> Library <colsep>Package <rowsep> ld.so <colsep>ldso <rowsep> ldconfig <colsep>ldso <rowsep> ldd <colsep>ldso <rowsep> libc.so.4 <colsep>shlibs <rowsep> libX11.so.6.0 <colsep>xf_lib <rowsep> libXt.so.6.0 <colsep>xf_lib <rowsep> libX11.so.3 <colsep>oldlibs <rowsep> libXt.so.3 <colsep>oldlibs <rowsep> </tabular> <p>So, in this case, you will need the packages ldso, shlibs, xf_lib and oldlibs. In each of the contents-files for these packages, look for a line saying ``PACKAGE LOCATION'', it will tell you on which `disk' the package is, in our case it will tell us in which subdirectory we need to look. For our example, we would find the following locations: <tabular ca=ll> Package <colsep>Location <rowsep> ldso <colsep>diska2 <rowsep> shlibs <colsep>diska2 <rowsep> oldlibs <colsep>diskx6 <rowsep> xf_lib <colsep>diskx9 <rowsep> </tabular> <p>The locations called ``diskXX'' refer to the ``slakware/XX'' subdirectories of the distribution, others may be found in the ``contrib'' subdirectory. In this case, we could now retrieve the packages we need by retrieving the following files (relative to the root of the Slackware distribution tree): <tscreen> <verb> slakware/a2/ldso.tgz slakware/a2/shlibs.tgz slakware/x6/oldlibs/tgz slakware/x9/xf_lib.tgz </verb> </tscreen> <p>Extract the files from these gzipped tarfiles in your /compat/linux directory (possibly omitting or afterwards removing files you don't need), and you are done. <p><bf>See also:</bf> <verb> ftp.freebsd.org:pub/FreeBSD/2.0.5-RELEASE/xperimnt/linux-emu/README /usr/src/sys/i386/ibcs2/README.iBCS2 </verb> <sect><heading>How to Install Mathematica on FreeBSD<label id="mathematica"></heading> <p><em>Contributed by &a.rich and &a.chuck</em> This document shows how to install the Linux binary distribution of Mathematica 2.2 on FreeBSD 2.1. <p>Mathematica supports Linux but not FreeBSD as it stands. So once you have configured your system for Linux compatibility you have most of what you need to run Mathematica. <p>For those who already have the student edition of Mathematica for DOS the cost of upgrading to the Linux version at the time this was written, March 1996, was $45.00. It can be ordered directly from Wolfram at (217) 398-6500 and paid for by credit card. <sect1><heading>Unpacking the Mathematica distribution</heading> <p>The binaries are currently distributed by Wolfram on CDROM. The CDROM has about a dozen tar files, each of which is a binary distribution for one of the supported architectures. The one for Linux is named LINUX.TAR. You can, for example, unpack this into /usr/local/Mathematica: <tscreen> <verb> % cd /usr/local % mkdir Mathematica % cd Mathematica % tar -xvf /cdrom/LINUX.TAR </verb> </tscreen> <sect1><heading>Obtaining your Mathematica Password</heading> <p>Before you can run Mathematica you will have to obtain a password from Wolfram that corresponds to your `machine ID.' <p>Once you have installed the linux compatibility runtime libraries and unpacked the mathematica you can obtain the `machine ID' by running the program `mathinfo' in the Install directory. <tscreen> <verb> % cd /usr/local/Mathematica/Install % mathinfo LINUX: 'ioctl' fd=5, typ=0x89(), num=0x27 not implemented richc.isdn.bcm.tmc.edu 9845-03452-90255 % </verb> </tscreen> So, for example, the `machine ID' of `richc' is `9845-03452-90255'. You can ignore the message about the ioctl that is not implemented. It won't prevent Mathematica from running in any way and you can safely ignore it, though you will see the message every time you run Mathematica. <p>When you register with Wolfram, either by email, phone or fax, you'll give them the 'machine ID' and they will respond with a corresponding password consisting of groups of numbers. You need to add them both along with the machine name and license number in your mathpass file. You can do this by invoking: <tscreen> <verb> % cd /usr/local/Mathematica/Install % math.install </verb> </tscreen> It will ask you to enter your license number and the Wolfram supplied password. If you get them mixed up or for some reason the math.install fails, That's OK, because you can simply edit the file 'mathpass' in this same directory to correct the info manually. <p>After getting past the password, math.install will ask you if you accept their canned install defaults, or if you want to use your own. If you are like us and distrust all install programs, you probably want to specify the actual directories. Beware. Although the math.install program asks you to specify directories, it won't create them for you, so you should perhaps have a second window open with another shell so that you can create them before you give them to the install program. Or, if it fails, you can create the directories and then restart the math.install program. The directories we chose to create beforehand and specify to math.install were: <tscreen> <verb> /usr/local/Mathematica/bin for binaries /usr/local/Mathematica/man/man1 for man pages /usr/local/Mathematica/lib/X11 for the XKeysymb file </verb> </tscreen> You can also tell it to use /tmp/math.record for the system record file, where it puts logs of sessions. After this math.install will continue on to unpacking things and placing everything where it should go. <p>The Mathematica Notebook feature is included separately, as the X Front End, and you have to install it separately. To get the X Front End stuff correctly installed, cd into the /usr/local/Mathematica/FrontEnd directory and executed the ./xfe.install shell script. You'll have to tell it where to put things, but you don't have to create any directories because it uses all the same directories that had been created for math.install. When it finished, there should be a new shell script in /usr/local/Mathematica/bin called "mathematica". <p>Lastly, you need to modify each of the shell scripts that Mathematica has installed. At the beginning of every shell script in /usr/local/Mathematica/bin add the following line: <tscreen> <verb> XKEYSYMDB=/usr/local/Mathematica/lib/X11/XKeysymDB; export XKEYSYMDB </verb> </tscreen> This tells Mathematica were to find it's own version of the key mapping file XKeysymDB. Without this you will get pages of error messages about missing key mappings. On FreeBSD-stable you need to add the following as well: <tscreen> <verb> RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF </verb> </tscreen> This tells Mathematica to use the linux version of host.conf. This file has a different syntax from FreeBSD's host.conf, so you'll get an error message about /etc/host.conf if you leave this out. <p>You might want to also modify your /etc/manpath.config file to read the new man directory, and you may need to edit your ~/.cshrc file to add /usr/local/Mathematica/bin to your path. <p>That's about all it takes, With this you should be able to type "mathematica" and get a really slick looking Mathematica Notebook screen up. Mathematica has included the Motif user interfaces, but it's compiled in statically, so you don't need the Motif libraries. Good luck doing this yourself! <sect1><heading>Bugs</heading> <p>The Notebook front end is known to hang sometimes when reading notebook files with an error messages similar to: <tscreen> <verb> File .../Untitled-1.mb appears to be broken for OMPR.257.0 </verb> </tscreen> We haven't found the cause for this, but it only affects the Notebook's X window front end, not the mathematica engine itself. So the command line interface invoked by 'math' is unaffected by this bug. <sect1><heading>Acknowledgments</heading> <p>A well-deserved thanks should go to &a.sos; and &a.peter; who made linux emulation what it is today, and Michael Smith who drove these two guys like dogs to get it to the point where it runs Linux binaries better than linux! :-) diff --git a/handbook/nutshell.sgml b/handbook/nutshell.sgml index 6f0b063db7..703453f4bd 100644 --- a/handbook/nutshell.sgml +++ b/handbook/nutshell.sgml @@ -1,151 +1,151 @@ -<!-- $Id: nutshell.sgml,v 1.9 1996-05-16 23:18:07 mpp Exp $ --> +<!-- $Id: nutshell.sgml,v 1.10 1996-08-21 07:28:54 asami Exp $ --> <!-- The FreeBSD Documentation Project --> <sect><heading>FreeBSD in a nutshell<label id="nutshell"></heading> <p>FreeBSD is a state of the art operating system for personal computers based on the Intel CPU architecture, which includes the 386, 486 and Pentium processors (both SX and DX versions). Intel compatible CPUs from AMD and Cyrix are supported as well. FreeBSD provides you with many advanced features previously available only on much more expensive computers. These features include: <itemize> <item><bf>Preemptive multitasking</bf> with dynamic priority adjustment to ensure smooth and fair sharing of the computer between applications and users.</item> <item><bf>Multiuser</bf> access means that many people can use a FreeBSD system simultaneously for a variety of things. System peripherals such as printers and tape drives are also properly SHARED BETWEEN ALL users on the system.</item> <item>Complete <bf>TCP/IP networking</bf> including SLIP, PPP, NFS and NIS support. This means that your FreeBSD machine can inter-operate easily with other systems as well act as an enterprise server, providing vital functions such as NFS (remote file access) and e-mail services or putting your organization on the Internet with WWW, ftp, routing and firewall (security) services.</item> <item><bf>Memory protection</bf> ensures that applications (or users) cannot interfere with each other. One application crashing will not affect others in any way.</item> <item>FreeBSD is a <bf>32-bit</bf> operating system and was designed as such from the ground up.</item> <item>The industry standard <bf>X Window System</bf> (X11R6) provides a graphical user interface (GUI) for the cost of a common VGA card and monitor and comes with full sources.</item> <item><bf>Binary compatibility</bf> with many programs built for SCO, BSDI, NetBSD, Linux and 386BSD.</item> <item>Hundreds of <bf>ready-to-run</bf> applications are available from the FreeBSD <bf>ports</bf> and <bf>packages</bf> collection. Why search the net when you can find it all right here?</item> <item>Thousands of additional and <bf>easy-to-port</bf> applications available on the Internet. FreeBSD is source code compatible with most popular commercial Unix systems and thus most applications require few, if any, changes to compile.</item> <item>Demand paged <bf>virtual memory</bf> and `merged VM/buffer cache' design efficiently satisfies applications with large appetites for memory while still maintaining interactive response to other users.</item> <item><bf>Shared libraries</bf> (the Unix equivalent of MS-Windows DLLs) provide for efficient use of disk space and memory.</item> <item>A full compliment of <bf>C</bf>, <bf>C++</bf> and <bf>Fortran</bf> development tools. Many additional languages for advanced research and development are also available in the ports and packages collection.</item> <item><bf>Source code</bf> for the entire system means you have the greatest degree of control over your environment. Why be locked into a proprietary solution and at the mercy of your vendor when you can have a truly Open System?</item> <item>Extensive <bf>on-line documentation</bf>.</item> <item><bf>And many more!</bf></item> </itemize> - FreeBSD is based on the BSD 4.4-lite release from Computer + FreeBSD is based on the 4.4BSD-Lite release from Computer Systems Research Group (CSRG) at the University of California at Berkeley, and carries on the distinguished tradition of BSD systems development. In addition to the fine work provided by CSRG, the FreeBSD Project has put in many thousands of hours in fine tuning the system for maximum performance and reliability in real-life load situations. As many of the commercial giants struggle to field PC operating systems with such features, performance and reliability, FreeBSD can offer them <bf>now</bf>! The applications to which FreeBSD can be put are truly limited only by your own imagination. From software development to factory automation, inventory control to azimuth correction of remote satellite antennae; if it can be done with a commercial UNIX product then it is more than likely that you can do it with FreeBSD, too! FreeBSD also benefits significantly from the literally thousands of high quality applications developed by research centers and universities around the world, often available at little to no cost. Commercial applications are also available and appearing in greater numbers every day. Because the source code for FreeBSD itself is generally available, the system can also be customized to an almost unheard of degree for special applications or projects, and in ways not generally possible with operating systems from most major commercial vendors. Here is just a sampling of some of the applications in which people are currently using FreeBSD: <itemize> <item><bf>Internet Services:</bf> The robust TCP/IP networking built into FreeBSD makes it an ideal platform for a variety of Internet services such as: <itemize> <item>FTP servers</item> <item>World Wide Web servers</item> <item>Gopher servers</item> <item>Electronic Mail servers</item> <item>USENET News</item> <item>Bulletin Board Systems</item> <item>And more...</item> </itemize> You can easily start out small with an inexpensive 386 class PC and upgrade as your enterprise grows.</item> <item><bf>Education:</bf> Are you a student of computer science or a related engineering field? There is no better way of learning about operating systems, computer architecture and networking than the hands on, under the hood experience that FreeBSD can provide. A number of freely available CAD, mathematical and graphic design packages also make it highly useful to those who's primary interest in a computer is to get <em>other</em> work done!</item> <item><bf>Research:</bf> With source code for the entire system available, FreeBSD is an excellent platform for research in operating systems as well as other branches of computer science. FreeBSD's freely available nature also makes it possible for remote groups to collaborate on ideas or shared development without having to worry about special licensing agreements or limitations on what may be discussed in open forums.</item> <item><bf>Networking:</bf> Need a new router? A name server (DNS)? A firewall to keep people out of your internal network? FreeBSD can easily turn that unused 386 or 486 PC sitting in the corner into an advanced router with sophisticated packet filtering capabilities. </item> <item><bf>X Window workstation:</bf> FreeBSD is a fine choice for an inexpensive X terminal solution, either using the freely available XFree86 server or one of the excellent commercial servers provided by X Inside. Unlike an X terminal, FreeBSD allows many applications to be run locally, if desired, thus relieving the burden on a central server. FreeBSD can even boot "diskless", making individual workstations even cheaper and easier to administer.</item> <item><bf>Software Development:</bf> The basic FreeBSD system comes with a full compliment of development tools including the renowned GNU C/C++ compiler and debugger. </item> </itemize> FreeBSD is available in both source and binary form on CDROM and via anonymous ftp. See <ref id="mirrors" name="Obtaining FreeBSD"> for more details. diff --git a/handbook/relnotes.sgml b/handbook/relnotes.sgml index 19a2790f58..57d451dc9a 100644 --- a/handbook/relnotes.sgml +++ b/handbook/relnotes.sgml @@ -1,594 +1,594 @@ -<!-- $Id: relnotes.sgml,v 1.12 1996-05-16 23:25:18 mpp Exp $ --> +<!-- $Id: relnotes.sgml,v 1.13 1996-08-21 07:28:57 asami Exp $ --> <!-- The FreeBSD Documentation Project --> <!-- <!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'> <linuxdoc><book><chapt>foo --> <sect><heading>About the current release<label id="relnotes"></heading> - <p>FreeBSD is a freely available, full source 4.4 BSD - Lite based release for Intel i386/i486/Pentium (or + <p>FreeBSD is a freely available, full source 4.4BSD-Lite + based release for Intel i386/i486/Pentium (or compatible) based PC's. It is based primarily on software from U.C. Berkeley's CSRG group, with some enhancements from NetBSD, 386BSD, and the Free Software Foundation. Since our release of FreeBSD 2.0 one year ago, the performance, feature set, and stability of FreeBSD has improved dramatically. The largest change is a revamped VM system with a merged VM/file buffer cache that not only increases performance, but reduces FreeBSD's memory footprint, making a 5MB configuration a more acceptable minimum. Other enhancements include full NIS client and server support, transaction TCP support, dial-on-demand PPP, an improved SCSI subsystem, early ISDN support, support for FDDI and Fast Ethernet (100Mbit) adapters, improved support for the Adaptec 2940 (WIDE and narrow) and many hundreds of bug fixes. We have also taken the comments and suggestions of many of our users to heart and have attempted to provide what we hope is a more sane and easily understood installation process. Your feedback on this (constantly evolving) process is especially welcome! In addition to the base distributions, FreeBSD offers a new ported software collection with some 350 commonly sought-after programs. The list of ports ranges from http (WWW) servers, to games, languages, editors and almost everything in between. The entire ports collection requires only 10MB of storage, all ports being expressed as ``deltas'' to their original sources. This makes it much easier for us to update ports, and greatly reduces the disk space demands made by the older 1.0 ports collection. To compile a port, you simply change to the directory of the program you wish to install, type make and let the system do the rest. The full original distribution for each port you build is retrieved dynamically off of CDROM or a local ftp site, so you need only enough disk space to build the ports you want. (Almost) every port is also provided as a pre-compiled "package" which can be installed with a simple command (pkg_add) by those who do not wish to compile their own ports from source. A number of additional documents which you may find very helpful in the process of installing and using FreeBSD may now also be found in the <bf>/usr/share/doc</bf> directory on any machine running FreeBSD 2.1 or later. You may view the manuals with any HTML capable browser with the following URLs: <descrip> <tag>The FreeBSD handbook</tag> <htmlurl url="file:/usr/share/doc/handbook/handbook.html"> <tag>The FreeBSD FAQ</tag> <htmlurl url="file:/usr/share/doc/FAQ/freebsd-faq.html"> </descrip> You can also visit the master (and most frequently updated) copies at <htmlurl url="http://www.freebsd.org" name="http://www.freebsd.org">. The core of FreeBSD does not contain DES code which would inhibit its being exported outside the United States. There is an add-on package to the core distribution, for use only in the United States, that contains the programs that normally use DES. The auxiliary packages provided separately can be used by anyone. A freely (from outside the U.S.) exportable European distribution of DES for our non-U.S. users also exists and is described in the <htmlurl url="../FAQ/freebsd-faq.html" name="FreeBSD FAQ">. If password security for FreeBSD is all you need, and you have no requirement for copying encrypted passwords from different hosts (Suns, DEC machines, etc) into FreeBSD password entries, then FreeBSD's MD5 based security may be all you require! We feel that our default security model is more than a match for DES, and without any messy export issues to deal with. If you are outside (or even inside) the U.S., give it a try! <![ IGNORE [ <p>Since our first release of FreeBSD 1.0 nearly two years ago, FreeBSD has changed dramatically. Since - release 2.0, FreeBSD has been based on the Berkeley BSD - 4.4-lite code rather than the Net2 code used for + release 2.0, FreeBSD has been based on the Berkeley + 4.4BSD-Lite code rather than the Net2 code used for previous versions. In addition to clearing the legal issues that surrounded the Net2 code, the port to 4.4 has also brought in numerous new features, filesystems and enhanced driver support. Since our release of FreeBSD 2.0 in November of 1994, the performance, feature set, and stability of FreeBSD has improved dramatically. The largest change is a revamped Virtual Memory (VM) system with a merged virtual memory and file buffer cache. This increases performance while reducing FreeBSD's memory footprint, making a system with 4 megabytes of RAM a more acceptable minimum. Other enhancements include full NIS client and server support, transaction TCP support, dial on demand PPP, an improved SCSI subsystem, early support for ISDN, support for FDDI and 100Mbit Fast Ethernet adapters, improved support for the Adaptec 2940 and hundreds of bug fixes. We have also taken the comments and suggestions of many of our users to heart and have attempted to provide what we hope is a more sane and easily understood installation process. Your feedback on this constantly evolving process is especially welcome! In addition to the base distributions, FreeBSD offers a new ported software collection with some 270 commonly sought-after programs. The list of ports ranges from World Wide Web (http) servers, to games, languages, editors and almost everything in between. The entire ports collection requires only 10MB of storage because each port contains only the changes required for the source code to compile on FreeBSD and the information necessary to automatically retrieve the original sources. The original distribution for each port you build is automatically retrieved off of CD-ROM or a via anonymous ftp, so you need only enough disk space to build the ports you want. Each port is also provided as a pre-compiled package which can be installed with the <tt>pkg_add(1)</tt> command for those who do not wish to compile their own ports from source. See <ref id="ports" name="The Ports Collection"> for a more complete description. <!-- XXX make xref For a list of contributors and a general project description, please see the file "CONTRIB.FreeBSD" which should be bundled with your binary distribution. Also see the "REGISTER.FreeBSD" file for information on registering with the "Free BSD user counter". This counter is for ALL freely available variants of BSD, not just FreeBSD, and we urge you to register yourself with it. --> The core of FreeBSD does not contain DES code which would inhibit its being exported outside the United States. An add-on package, for use only in the United States, contains the programs that normally use DES. The auxiliary packages provided separately can be used by anyone. A freely exportable European distribution of DES for our non-U.S. users also exists and is described in the <url url="http://www.freebsd.org/FAQ" name="FreeBSD FAQ">. If password security for FreeBSD is all you need, and you have no requirement for copying encrypted passwords from other hosts using DES into FreeBSD password entries, then FreeBSD's MD5 based security may be all you require. We feel that our default security model is more than a match for DES, and without any messy export issues to deal with. FreeBSD 2.0.5 represents the culmination of 2 years of work and many thousands of man hours put in by an international development team. We hope you enjoy it! <sect1><heading>New feature highlights</heading> <p>The following features were added or substantially improved between the release of 2.0 and this 2.0.5 release. In order to facilitate better communication, the person, or persons, responsible for each enhancement is noted. Any questions regarding the new functionality should be directed to them first. <sect2><heading>Kernel</heading> <p> <descrip> <tag>Merged VM-File Buffer Cache</tag> A merged VM/buffer cache design greatly enhances overall system performance and makes it possible to do a number of more optimal memory allocation strategies that were not possible before. Owner: David Greenman (davidg@FreeBSD.org) and John Dyson (dyson@implode.root.com) <tag>Network PCB hash optimization</tag> For systems with a great number of active TCP connections (WEB and ftp servers, for example), this greatly speeds up the lookup time required to match an incoming packet up to its associated connection. Owner: David Greenman (davidg@FreeBSD.org) <tag>Name cache optimization</tag> The name-cache would cache all files of the same name to the same bucket, which would put for instance all ".." entries in the same bucket. We added the parent directory version to frustrate the hash, and improved the management of the cache in various other ways while we were at it. Owner: Poul-Henning Kamp (phk@FreeBSD.org) David Greenman (davidg@FreeBSD.org) <tag>Less restrictive swap-spaces</tag> The need to compile the names of the swap devices into the kernel has been removed. Now <tt>swapon(8)</tt> will accept any block devices, up to the maximum number of swap devices configured in the kernel. Owner: Poul-Henning Kamp (phk@FreeBSD.org) David Greenman (davidg@FreeBSD.org) <tag>Hard Wired SCSI Devices</tag> Prior to 2.0.5, FreeBSD performed dynamic assignment of unit numbers to SCSI devices as they were probed, allowing a SCSI device failure to possibly change unit number assignment. This could cause filesystems other disks in the system to be incorrectly mounted, or not mounted at all. Hard wiring allows static allocation of unit numbers (and hence device names) to scsi devices based on SCSI ID and bus. SCSI configuration occurs in the kernel config file. Samples of the configuration syntax can be found in the <tt>scsi(4)</tt> man page or the LINT kernel config file. Owner: Peter Dufault (dufault@hda.com) Sources involved: <tt>sys/scsi/*</tt> <tt>usr.sbin/config/*</tt> <tag>Slice Support</tag> FreeBSD now supports a <em>slice</em> abstraction which enhances FreeBSD's ability to share disks with other operating systems. This support will allow FreeBSD to inhabit DOS extended partitions. Owner: Bruce Evans (bde@FreeBSD.org) Sources involved: <tt>sys/disklabel.h</tt> <tt>sys/diskslice.h</tt> <tt>sys/dkbad.h</tt> <tt>kern/subr_diskslice.c</tt> <tt>kern/subr_dkbad.c</tt> <tt>i386/isa/diskslice_machdep.c</tt> <tt>i386/isa/wd.c</tt> <tt>scsi/sd.c</tt> <tt>dev/vn/vn.c</tt> <tag>Support for Ontrack Disk Manager Version 6.0</tag> Support has been added for disks which use Ontrack Disk Manager. The fdisk program does <em>not</em> know about it however, so make all changes using the install program on the boot.flp or the Ontrack Disk Manager tool under MS-DOS. Owner: Poul-Henning Kamp (phk@FreeBSD.org) <tag>Bad144 is back and working</tag> Bad144 works again, though the semantics are slightly different than before in that the bad-spots are kept relative to the slice rather than absolute on the disk. Owner: Bruce Evans (bde@FreeBSD.org) Poul-Henning Kamp (phk@FreeBSD.org) </descrip> <sect2><heading>New device support</heading> <sect3><heading>SCSI and CDROM devices</heading> <p><descrip> <tag>Matsushita/Panasonic (Creative) CD-ROM driver</tag> The Matsushita/Panasonic CR-562 and CR-563 drives are now supported when connected to a Sound Blaster or 100% compatible host adapter. Up to four host adapters are supported for a total of 16 CD-ROM drives. The audio functions are supported with the Karoke variable speed playback. Owner: Frank Durda IV (bsdmail@nemesis.lonestar.org) Sources involved: <tt>isa/matcd</tt> <tag>Adaptec 2742/2842/2940 SCSI driver</tag> The original 274x/284x driver has evolved considerably since the 2.0 release of FreeBSD. We now offer full support for the 2940 series as well as the Wide models of these cards. The arbitration bug that caused problems with fast devices has been corrected and <em>experimental</em> tagged queuing support has been added (kernel option <tt>AHC_TAGENABLE</tt>). John Aycock has also released the sequencer code under a Berkeley style copyright making the driver entirely clean of the GPL. Owner: Justin Gibbs (gibbs@FreeBSD.org) Sources involved: <tt>isa/aic7770.c</tt> <tt>pci/aic7870.c</tt> <tt>i386/scsi/*</tt> <tt>sys/dev/aic7xxx/*</tt> <tag>NCR5380/NCR53400 SCSI (ProAudio Spectrum) driver</tag> Owner: core Submitted by: Serge Vakulenko (vak@cronyx.ru) Sources involved: <tt>isa/ncr5380.c</tt> <tag>Sony CDROM driver</tag> Owner: core Submitted by: Mikael Hybsch (micke@dynas.se) Sources involved: <tt>isa/scd.c</tt> </descrip> <sect3><heading>Serial devices</heading> <p><descrip> <tag>SDL Communications Riscom/8 Serial Board Driver</tag> Owner: Andrey Chernov (ache@FreeBSD.org) Sources involved: <tt>isa/rc.c</tt> <tt>isa/rcreg.h</tt> <tag>Cyclades Cyclom-y Serial Board Driver</tag> Owner: Bruce Evans (bde@FreeBSD.org) Submitted by: Andrew Werple (andrew@werple.apana.org.au) and Heikki Suonsivu (hsu@cs.hut.fi) Obtained from: NetBSD Sources involved: <tt>isa/cy.c</tt> <tag>Cronyx/Sigma sync/async serial driver</tag> Owner: core Submitted by: Serge Vakulenko Sources involved: <tt>isa/cronyx.c</tt> </descrip> <sect2><heading>Networking</heading> <p><descrip> <tag>Diskless booting</tag> Diskless booting in 2.0.5 is much improved over previous releases. The boot program is in <tt>src/sys/i386/boot/netboot</tt>, and can be run from an MS-DOS system or burned into an EPROM. WD, SMC, 3COM and Novell ethernet cards are currently supported. Local swapping is also supported. <tag>DEC DC21140 Fast Ethernet driver</tag> This driver supports any of the numerous NICs using the DC21140 chipset including the 100Mb DEC DE-500-XA and SMC 9332. Owner: core Submitted by: Matt Thomas (thomas@lkg.dec.com) Sources involved: <tt>pci/if_de.c</tt> <tt>pci/dc21040.h</tt> <tag>DEC FDDI (DEFPA/DEFEA) driver</tag> Owner: core Submitted by: Matt Thomas (thomas@lkg.dec.com) Sources involved: <tt>pci/if_pdq.c</tt> <tt>pci/pdq.c</tt> <tt>pci/pdq_os.h</tt> <tt>pci/pdqreg.h</tt> <tag>3Com 3c505 (Etherlink/+) NIC driver</tag> Owner: core Submitted by: Dean Huxley (dean@fsa.ca) Obtained from: NetBSD Sources involved: <tt>isa/if_eg.c</tt> <tag>Fujitsu MB86960A family of NICs driver</tag> Owner: core Submitted by: M.S. (seki@sysrap.cs.fujitsu.co.jp) Sources involved: <tt>isa/if_fe.c</tt> <tag>Intel EtherExpress driver</tag> Owner: Rodney W. Grimes (rgrimes@FreeBSD.org) Sources involved: <tt>isa/if_ix.c</tt> <tt>isa/if_ixreg.h</tt> <tag>3Com 3c589 driver</tag> Owner: core Submitted by: "HOSOKAWA Tatsumi" (hosokawa@mt.cs.keio.ac.jp), Seiji Murata (seiji@mt.cs.keio.ac.jp) and Noriyuki Takahashi (hor@aecl.ntt.jp) Sources involved: <tt>isa/if_zp.c</tt> <tag>IBM Credit Card Adapter driver</tag> Owner: core Submitted by: "HOSOKAWA Tatsumi" (hosokawa@mt.cs.keio.ac.jp), Sources involved: <tt>isa/pcic.c</tt> <tt>isa/pcic.h</tt> <tag>EDSS1 and 1TR6 ISDN interface driver</tag> Owner: core Submitted by: Dietmar Friede (dfriede@drnhh.neuhaus.de) and Juergen Krause (jkr@saarlink.de) Sources involved: <tt>gnu/isdn/*</tt> </descrip> <sect2><heading>Miscellaneous drivers</heading> <p><descrip> <tag>Joystick driver</tag> Owner: Jean-Marc Zucconi (jmz@FreeBSD.org) Sources involved: <tt>isa/joy.c</tt> <tag>National Instruments ``LabPC'' driver</tag> Owner: Peter Dufault (dufault@hda.com) Sources involved: <tt>isa/labpc.c</tt> <tag>WD7000 driver</tag> Owner: Olof Johansson (offe@ludd.luth.se) <tag>Pcvt Console driver</tag> Owner: Jörg Wunsch (joerg@FreeBSD.org) Submitted by: Hellmuth Michaelis (hm@altona.hamburg.com) Sources involved: <tt>isa/pcvt/*</tt> <tag>BSD-audio emulator for VAT driver</tag> Owner: Amancio Hasty (ahasty@FreeBSD.org) and Paul Traina (pst@FreeBSD.org) Sources involved: <tt>isa/sound/vat_audio.c</tt> <tt>isa/sound/vat_audioio.h</tt> <tag>National Instruments AT-GPIB and AT-GPIB/TNT GPIB driver</tag> Owner: core Submitted by: Fred Cawthorne (fcawth@delphi.umd.edu) Sources involved: <tt>isa/gpib.c</tt> <tt>isa/gpib.h</tt> <tt>isa/gpibreg.h</tt> <tag>Genius GS-4500 hand scanner driver</tag> Owner: core Submitted by: Gunther Schadow (gusw@fub46.zedat.fu-berlin.de) Sources involved: <tt>isa/gsc.c</tt> <tt>isa/gscreg.h</tt> <tag>CORTEX-I Frame Grabber</tag> Owner: core Submitted by: Paul S. LaFollette, Jr. ( Sources involved: <tt>isa/ctx.c</tt> <tt>isa/ctxreg.h</tt> <tag>Video Spigot video capture card</tag> Owner: Jim Lowe </descrip> <sect1><heading>Experimental features</heading> <p><descrip> <tag>UNIONFS and LFS</tag> The unionfs and LFS file systems are known to be severely broken in FreeBSD 2.0.5. This is in part due to old bugs that we have not had time to resolve yet and the need to update these file systems to deal with the new VM system. We hope to address these issues in a later release of FreeBSD. <tag>iBCS2 Support</tag> FreeBSD now supports running iBCS2 compatible binaries. Currently SCO UNIX 3.2.2 and 3.2.4, and ISC 2.2 COFF are supported. The iBCS2 emulator is in its early stages and has not been extensively tested, but it is functional. Most of SCO's 3.2.2 binaries work, as does an old INFORMIX-2.10 for SCO. Further testing is necessary to complete this project. There is also work under way for ELF and XOUT loaders, and most of the svr4 syscall wrappers are written. Owner: Søren Schmidt (sos) and Sean Eric Fagan (sef) Sources involved: <tt>sys/i386/ibcs2/*</tt> and misc kernel changes. </descrip> <!-- <sect1><heading>Reporting problems, making suggestions, submitting code</heading> <p>Your suggestions, bug reports and contributions of code are always valued - please do not hesitate to report any problems you may find (preferably with a fix attached if you can!). The preferred method to submit bug reports from a machine with Internet mail connectivity is to use the send-pr command. Bug reports will be dutifully filed by our faithful bug-filer program and you can be sure that we will do our best to respond to all reported bugs as soon as possible. If, for some reason, you are unable to use the send-pr command to submit a bug report, you can try to send it to: <tscreen>bugs@FreeBSD.org</tscreen> Otherwise, for any questions or suggestions, please send mail to: <tscreen>questions@FreeBSD.org</tscreen> Additionally, being a volunteer effort, we are always happy to have extra hands willing to help - there are already far more enhancements to be done than we can ever manage to do by ourselves! To contact us on technical matters, or with offers of help, you may send mail to: <tscreen>hackers@FreeBSD.org</tscreen> Since these mailing lists can experience significant amounts of traffic, if you have slow or expensive mail access and you are only interested in keeping up with significant FreeBSD events, you may find it preferable to subscribe to: <tscreen>announce@FreeBSD.org</tscreen> All but the freebsd-bugs groups can be freely joined by anyone wishing to do so. Send mail to &a.majordomo and include the keyword `help' on a line by itself somewhere in the body of the message. This will give you more information on joining the various lists, accessing archives, etc. There are a number of mailing lists targeted at special interest groups not mentioned here, so send mail to majordomo and ask about them! --> ]]>