diff options
| author | Peter Wemm <peter@FreeBSD.org> | 1995-12-30 19:02:48 +0000 |
|---|---|---|
| committer | Peter Wemm <peter@FreeBSD.org> | 1995-12-30 19:02:48 +0000 |
| commit | a5b996a7ecea192e05c848269fbfb40c1e7c50ef (patch) | |
| tree | b43d0e66d9963acc026a6322b81fd219d273736b /share/FAQ/Text | |
| parent | df2fbf15a2e56a16c3b54b93a3369b662b6f20e5 (diff) | |
Notes
Diffstat (limited to 'share/FAQ/Text')
25 files changed, 0 insertions, 7591 deletions
diff --git a/share/FAQ/Text/CONTRIB.FreeBSD b/share/FAQ/Text/CONTRIB.FreeBSD deleted file mode 100644 index 16e46b5bcf51..000000000000 --- a/share/FAQ/Text/CONTRIB.FreeBSD +++ /dev/null @@ -1,278 +0,0 @@ - FreeBSD 2.0.5 - 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 reimplemented from the -4.4 BSD 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 endevors. - - -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's been most useful! - -Thanks to Chuck Robey (chuckr@eng.umd.edu) who's been contributing his -floppy tape streamer for experimental work. - - -The FreeBSD Core Team -(in alphabetical order): - - Andrey A. Chernov <ache@FreeBSD.org> - Bruce Evans <bde@FreeBSD.org> - David Greenman <davidg@FreeBSD.org> - Garrett A. Wollman <wollman@FreeBSD.org> - Gary Palmer <gpalmer@FreeBSD.org> - Jörg Wunsch <joerg@FreeBSD.org> - John Dyson <dyson@FreeBSD.org> - Jordan K. Hubbard <jkh@FreeBSD.org> - Justin Gibbs <gibbs@FreeBSD.org> - Poul-Henning Kamp <phk@FreeBSD.org> - Rich Murphey <rich@FreeBSD.org> - Rodney W. Grimes <rgrimes@FreeBSD.org> - Satoshi Asami <asami@FreeBSD.org> - Søren Schmidt <sos@FreeBSD.org> - - -Who's Responsible For What: - - President: Jordan K. Hubbard <jkh@FreeBSD.org> - Principle Architect: David Greenman <davidg@FreeBSD.org> - Documentation: John Fieber <jfieber@FreeBSD.org> - Internationalization: Andrey A. Chernov <ache@FreeBSD.org> - Networking: Garrett A. Wollman <wollman@FreeBSD.org> - Postmaster: Jonathan M. Bresler <jmb@FreeBSD.org> - Public Relations: Jordan Hubbard <jkh@FreeBSD.org> - Release Coordinator: Jordan Hubbard <jkh@FreeBSD.org> - System Administration: Gary Palmer <gpalmer@FreeBSD.org> - WEBMASTERS: John Fieber <jfieber@FreeBSD.org> and - James L. Robinson <jlrobin@FreeBSD.org> - XFree86 Project, Inc. Liason: Rich Murphey <rich@FreeBSD.org> - - -Additional FreeBSD Contributors -(in alphabetical order by first name, just to be different): - -Adam David <adam@veda.is> -Adam Glass <glass@postgres.berkeley.edu> -Akito Fujita <fujita@zoo.ncl.omron.co.jp> -Andras Olah <olah@cs.utwente.nl> -Andreas Klemm <andreas@knobel.GUN.de> -Andrew Herbert <andrew@werple.apana.org.au> -Andrew Moore <alm@FreeBSD.org> -Anthony Yee-Hang Chan <yeehang@netcom.com> -Atsushi Murai <amurai@spec.co.jp> -Bill Fenner <fenner@parc.xerox.com> -Bill Paul <wpaul@FreeBSD.org> -Bob Wilcox <bob@obiwan.uucp> -Brian Tao <taob@gate.sinica.edu.tw> -Charles Hannum <mycroft@ai.mit.edu> -Chris G. Demetriou <cgd@postgres.berkeley.edu> -Chris Provenzano <proven@athena.mit.edu> -Chris Stenton <jacs@gnome.co.uk> -Chris Torek <torek@ee.lbl.gov> -Christian Gusenbauer <cg@fimp01.fim.uni-linz.ac.at> -Christoph Robitschko <chmr@edvz.tu-graz.ac.at> -Chuck Robey <chuckr@Glue.umd.edu> -Cornelis van der Laan <nils@guru.ims.uni-stuttgart.de> -Craig Struble <cstruble@vt.edu> -Curt Mayer <curt@toad.com> -Danny J. Zerkel <dzerkel@feephi.phofarm.com> -Dave Burgess <burgess@hrd769.brooks.af.mil> -Dave Chapeskie <dchapes@zeus.leitch.com> -Dave Rivers <rivers@ponds.uucp> -David Dawes <dawes@physics.su.OZ.AU> -Dean Huxley <dean@fsa.ca> -Don Whiteside <dwhite@anshar.shadow.net> -Eric L. Hernes <erich@lodgenet.com> -Frank Durda IV <bsdmail@nemesis.lonestar.org> -Frank Maclachlan <fpm@crash.cts.com> -Frank Nobis <fn@trinity.radio-do.de> -Gary A. Browning <gab10@griffcd.amdahl.com> -Gary Clark II <gclarkii@radon.gbdata.com> -Gary Jennejohn <gj%pcs.dec.com@inet-gw-1.pa.dec.com> -Gene Stark <stark@cs.sunysb.edu> -Guido van Rooij <guido@gvr.win.tue.nl> -Havard Eidnes <Havard.Eidnes@runit.sintef.no> -Holger Veit <Holger.Veit@gmd.de> -Ishii Masahiro, R. Kym Horsell -J.T. Conklin <jtc@winsey.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> -Jim Wilson <wilson@moria.cygnus.com> -Josh MacDonald <jmacd@uclink.berkeley.edu> -Jörg Wunsch <joerg_wunsch@uriah.heep.sax.de> -Julian Elischer <julian@dialix.oz.au> -Julian Stacey <stacey@guug.de> <fallback: <julian@meepmeep.pcs.com>> -Keith Bostic <bostic@toe.CS.Berkeley.EDU> -Keith Moore <?> -Kirk McKusick <mckusick@mckusick.com> -L Jonas Olsson <ljo@po.cwru.edu> -Lars Fredriksen <fredriks@mcs.com> -Lucas James <Lucas.James@ldjpc.apana.org.au> -Marc Frajola <marc@dev.com> -Marc Ramirez <mrami@mramirez.sy.yale.edu -Mark Murray <mark@grondar.za> -Mark Tinguely <tinguely@plains.nodak.edu> <tinguely@hookie.cs.ndsu.NoDak.edu> -Marc van Kempen <wmbfmk@urc.tue.nl> -Martin Birgmeier -Martin Renters <martin@innovus.com> -Matt Thomas <thomas@lkg.dec.com> -Michael Smith <msmith@atrad.adelaide.edu.au> -Nate Williams <nate@FreeBSD.org> -NIIMI Satoshi <sa2c@and.or.jp> -Nobuhiro Yasutomi <nobu@@psrc.isac.co.jp> -Nobuyuki Koganemaru <kogane@kces.koganemaru.co.jp> -Ollivier Robert <roberto@FreeBSD.org> -Paul Kranenburg <pk@cs.few.eur.nl> -Paul Mackerras <paulus@cs.anu.edu.au> -Paul Traina <pst@cisco.com> -Paul Richards <paul@FreeBSD.org> -Peter Dufault <dufault@hda.com> -Peter Wemm <peter@haywire.DIALix.COM> -Philippe Charnier <charnier@lirmm.fr> -Rob Shady <rls@id.net> -Rob Snow <rsnow@txdirect.net> -Richard Stallman <rms@gnu.ai.mit.edu> -Sascha Wildner <swildner@channelz.GUN.de> -Scott Mace <smace@FreeBSD.org> -Sean Eric Fagan <sef@kithrup.com> -Serge V. Vakulenko <vak@zebub.msk.su> -Stefan Esser <se@MI.Uni-Koeln.DE> -Stephen McKay <syssgm@devetir.qld.gov.au> -Steve Gerakines <steve2@genesis.tiac.net> -Steven Wallace <swallace@ece.uci.edu> -Tatsumi Hosokawa <hosokawa@mt.cs.keio.ac.jp> -Terry Lee <terry@uivlsi.csl.uiuc.edu> -Theo Deraadt <deraadt@fsa.ca> -Thomas Gellekum <thomas@ghpc8.ihf.rwth-aachen.de> -Tom Samplonius <tom@misery.sdf.com> -Torbjorn Granlund <tege@matematik.su.se> -Torsten Blum <torstenb@FreeBSD.ORG> -Ugen J.S.Antsilevich <ugen@NetVision.net.il> -Werner Griessl <werner@btp1da.phy.uni-bayreuth.de> -Wolfgang Stanglmeier <wolf@kintaro.cologne.de> -Wolfram Schneider <wosch@cs.tu-berlin.de> -Yuval Yarom <yval@cs.huji.ac.il> -Yves Fonk <yves@cpcoup5.tn.tudelft.nl> - - -386BSD Patch kit patch contributors (in alphabetical order): - -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@winsey.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> -Joerg Lohse <lohse@tech7.informatik.uni-hamburg.de> -Jörg Wunsch <joerg_wunsch@uriah.heep.sax.de> -John Dyson - <formerly dyson@ref.tfs.com> -John Woods <jfw@eddie.mit.edu> -Jordan K. Hubbard <jkh@whisker.hubbard.ie> -Julian Elischer <julian@dialix.oz.au> -Julian Stacey <stacey@guug.de> <fallback: <julian@meepmeep.pcs.com>> -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@innovus.com> -Michael Galassi <nerd@percival.rain.com> -Mike Durkin <mdurkin@tsoft.sf-bay.org> -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> -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> - -Last, but not least, the release engineer would like to thank: - His Wife, for chocolate chip cookies, and some other things. - The DGB project @ TFS, for patience and tolerance. - -$Id: CONTRIB.FreeBSD,v 1.23 1995/08/31 15:17:02 jkh Exp $ diff --git a/share/FAQ/Text/ESDI.FAQ b/share/FAQ/Text/ESDI.FAQ deleted file mode 100644 index 8d869240d6f3..000000000000 --- a/share/FAQ/Text/ESDI.FAQ +++ /dev/null @@ -1,187 +0,0 @@ - FreeBSD - Using "Mature Technology" (MFM, ESDI) hard drives - -First, please read and make sure that you understand the "diskspace" FAQ. - -The term "partition" has become overloaded when referring to an area of a -hard disk drive. I will use "slice" in this document to refer to an area -which is a "partition" to DOS FDISK. This usage is consistent with most of -current FreeBSD. I will use the word "partition" to refer to an area de- -fined by a FreeBSD disklabel, of which there is one per FreeBSD slice. The -FreeBSD partitions may contain filesystems, swap space, or be available as -raw disk devices to applications. - -This document covers the steps you will need to perform before starting the -FreeBSD installation and which are specific to these types of disk drives. - -1 Disk layout planning -2 Disk installation (may already be done) -3 Low-level formatting (may or may not be required) - -If your drive is installed and formatted properly, careful planning is all -that you need to do. - -During the installation, there is only one special step that is required. -This is also one place where the FreeBSD taxonomic convention breaks down --- the assignment of slices is called "Partitioning" in the FreeBSD proce- -dures at the time of this writing. During that step, when you assign the -FDISK slices, be sure to specify that the bad144 lists should be created -(the "B" command). - -1 Disk layout planning ----------------------- - -To be able to make the right decisions regarding the setup of slices for -FreeBSD, you need to understand that the initial boot stages for FreeBSD -rely on the ROM BIOS, but that the ROM BIOS is not used in any way once the -FreeBSD kernel is loaded. After the kernel is loaded, it uses its own -driver instead of the BIOS to access the disk. - -These older disks do not do automatic bad block management. Some con- -trollers seem to do so, but this is a feature of the ROM BIOS on that con- -troller, and therefore is not available once FreeBSD is running. Other -controllers use a different method of bad sector handling (slipping), but -this feature can also induce translations in the sectoring which will pre- -vent successful installation. Do not use automatic sector mapping or sec- -tor slipping, even if it is supported on the controller, for the same rea- -sons that you cannot use a translated disk geometry. - -To be able to use these drives, the driver has to be able to substitute -good sectors for the bad ones. The FreeBSD filesystems assume "perfect" -disks, so the bad sector handling is done in the driver. The way this is -done is that a few copies of the list of bad sectors is kept at the end of -the slice. When a slice is opened, this list is read and kept in the driv- -er. On every access to the drive, the list is consulted to see if a sub- -stitute sector, also from the end of the slice, must be used rather than -the sector that the filesystem or application is actually asking for. This -list is called the bad144 list, which name comes from a Digital Equipment -Corporation standard for keeping this information. - -There are three reasons that you would be required to use more than one -FreeBSD slice on your disk, and all of them are more probable the larger -your drive is. - -1) The FreeBSD portion of your drive will extend beyond cylinder 1023. -2) The FreeBSD portion of your drive has (or is likely to have) more than - 126 bad sectors. -3) You need more than 7 filesystems for FreeBSD. - -It is not sufficient to make sure that the entire boot filesystem is inside -of cylinder 1024, unless it just so happens that that filesystem occupies a -flawless part of the disk. To be able to read the bad144 list during the -boot process (via the ROM BIOS), the end of the slice must be within the -first 1024 cylinders. There are also some boot managers, e.g. the OS/2 -boot manager, that require a bootable slice to be entirely below cylinder -1024. - -The bad144 data format only allows for 126 sectors to be mapped. If your -drive is large, it could easily have more than this many over its entire -size. I have a 320 Mb drive which is unusually error-filled, but still -within acceptable tolerances, and it has this problem (but it also has more -than 1024 cylinders, so I'd have had to split it, anyway). - -The FreeBSD disk label has room for 8 partitions. It is not recommended -that filesystems be placed on partitions b or c, even on non-booted slices, -so that leaves 6 partitions within each slice which may contain filesys- -tems. Older versions of FreeBSD did not support filesystems on partition d -either, but the slice-handling capability has eliminated that restriction. -It may be best to avoid using partition d if you can for compatibility pur- -poses. The installation procedures skip from a to e for this reason. - -2 Disk installation -------------------- - -Physical installation is outside the scope of this document. Consult the -documentation provided by your computer, controller, and disk drive ven- -dor(s). - -3 Low-level formatting ----------------------- - -If you are starting from scratch, you may need to low-level format your -drive(s). If you have been using your drive with the intended controller -for DOS or some other system, and will not be changing the physical orien- -tation of the drive, then you can skip this step. If the drive is new, if -you are changing the physical orientation of the drive, or it has been used -with a different controller, you may need to do the low-level format. Be -aware that some drives have jumpers on them to help compensate for changes -in physical orientation (horizontal, right side, or left side), but it is -highly recommended that, if you are changing the physical orientation of -the drive, you redo the low-level format. The "sag" of the disk head arma- -ture and other effects of gravity are quite significant at the sizes of the -bits and tracks on these drives. The greater the capacity of your drive, -the more critical this becomes. With 10-40Mb MFM drives, you may get away -with it. Beyond that, you are definitely rolling dice. - -The MFM drive format is standard, and a drive formatted on one manufacturer -and model of controller should work just fine on another, but ESDI drive -formats vary between manufacturers and sometimes even between models. A -new ESDI drive (yes, they can still be found new in the box, years old), or -one that has been in use on a different controller or in a different physi- -cal orientation will definitely require reformatting. - -As the ESDI specification developed, the ability to put the error map in- -formation (Manufacturer's Defect List, or MDL) on the drive was added. -Since it was not known how the drive would be formatted, or even what the -size of the data part of the sectors would be, each bad spot is expressed -as bytes from the index and length of the bad area in bits. This informa- -tion is recorded in a few different cylinders on each track and contains -only information pertinent to the corresponding head. The most universal -place for this information is in the last cylinder. Later ESDI drives sup- -port a "phantom" cylinder at 0xfff (4095) where this information is kept -- -the actual location of this cylinder is beyond the "last" cylinder reported -for data use. If your drive does not support cylinder 0xfff, or if your -controller doesn't know how to use it, and if you wish to preserve the man- -ufacturer's defect list, do not format the last cylinder of your drive. -The format of the MDL is such that regular data operations will not work on -a track containing that information. - -As a further caveat, it as been observed that some controllers hang if the -MDL area is accessed for data use, while others simply report an error and -go on with life. You will want to be careful to not include the MDL area -in any FreeBSD slice, but you will want to be especially careful in case -your controller is one of those that hangs if you miss. - -Now that you have decided how much of the drive to format, you can proceed -with the actual format process. How this is done varies widely from con- -troller to controller. For most of them, you need to jump into a special -location in the controller ROM using the DOS DEBUG program. For a few, -special software is provided on diskette for the controller. Because these -procedures and the ways to initiate them vary so much, it is outside of the -scope of this document to describe them. Consult the manufacturer's docu- -mentation for this procedure. - -Many of the controllers have the ability to read and use the MDL. Even -though you cannot use the controller's bad block mapping capability, which -is supported through the BIOS, it may be beneficial to allow the controller -to use this information during the format process. When the drive was -tested at the factory, it was tested at the operating margins, not just op- -timal conditions. Therefore, there may be entries in the MDL that would be -missed by a run-of-the-mill data scan. If the controller is permitted to -use the MDL during formatting, many of them will format the sector with a -special flag set in the sector preamble to guarantee that that sector will -show up as bad on a read. This is, in fact, the mechanism that some con- -trollers use to handle bad sector mapping, though FreeBSD does not use the -same mechanism. We can take advantage of this feature as a 'round about -way to get the MDL represented in the bad144 list. Having the sectors -which contain a bad spot formatted as bad will make certain that you don't -use a sector where some data patterns may fail even though the initial scan -passed that sector as OK. Even if the sector doesn't produce hard errors, -it may cause soft (correctable) errors and time-consuming retries. - -Finally, FreeBSD ----------------- - -Having made your careful plans and preparations, you are ready to use -FreeBSD on your MFM or ESDI disk drive. Don't forget to request bad block -scanning during the "Partition" slice assignment, and you should be on your -way to satisfying computing. Be prepared to allow time for the bad block -scan to take place. Depending on a variety of system parameters, such as -CPU speed, controller type, disk rotational and seek speeds, and so forth, -this process will take anywhere from several minutes to hours. If you for- -get to do the scan, it is likely that the installation will fail trying to -make the filesystems, and if it should make the filesystems, it will surely -fail when you start using them. - - John Lind, Starfire Consulting Services -E-mail: john@starfire.MN.ORG USnail: PO Box 17247, Mpls MN 55417 diff --git a/share/FAQ/Text/FreeBSD.FAQ b/share/FAQ/Text/FreeBSD.FAQ deleted file mode 100644 index a4d630143984..000000000000 --- a/share/FAQ/Text/FreeBSD.FAQ +++ /dev/null @@ -1,1307 +0,0 @@ - - FreeBSD - Frequently Asked Questions - For Version 2.0 - -Please mail all suggestions and additions to <FAQ@FreeBSD.ORG> - - -Revision: $Id: FreeBSD.FAQ,v 1.4 1995/04/09 07:02:03 jkh Exp $ - -All entries are assumed to be relevant to FreeBSD 2.0. -Any entries with a <XXX> are under construction. - - -Table of Contents ------------------ - -0 Preface -1 Installation -2 Hardware Compatibility -3 Commercial applications -4 User Applications -5 Miscellaneous Questions -6 Kernel Configuration -7 System Administration -8 Networking -9 Serial Communications - - - -0 Preface ---------- - -Welcome to the FreeBSD 2.0 FAQ! This document tries to answer some of -the most frequently asked questions about FreeBSD 2.0. -If there's something you're having trouble with and you do not see it -here, please send email to: - - <questions@FreeBSD.ORG> - - -Some of the instructions here will also refer to auxiliary utilities -in the /usr/src/share/FAQ directory. CDROM purchasers and net folks -who've grabbed the FreeBSD 2.0 `srcdist' will have these files. If -you don't have the source distribution, then you can either grab the -whole thing from: - - ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current - -Or you can grab only those files you're interested in straight out of -the FreeBSD-current distribution in: - - ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current/src - -0.1: What is FreeBSD? - -FreeBSD 2.0 is a UN*X type operating system based on U.C. Berkeley's -4.4BSD-lite release for the i386 platform. It is also based indirectly -on William Jolitz's port of U.C. Berkeley's Net/2 to the i386, 386BSD. -There have been many additions and bug fixes made throughout -the entire system, some of the highlights of which are: - - More robust and extensive PC device support - System V-style IPC, messaging and semaphores - Shared Libraries - Much improved virtual memory code - Better console driver support - Network booting (diskless) support - Yellow Pages support - Full support of the PCI bus - Loadable kernel modules - Too many additional utilities and applications to mention - -<2.X-Current> - Serial Console Support - Merged VM/Buffer Cache - On demand PPP - Sync PPP - Improved SCSI support - - -0.2: What are the FreeBSD mailing lists, and how can I get on them? - -The following mailing lists are provided for FreeBSD users and -developers. For more information, send to -<majordomo@FreeBSD.ORG> and include a single line saying -``help'' in the body of your message. - -announce: For announcements concerning FreeBSD. Low traffic. Subscribe! -hackers: Useful for persons wishing to work on the internals. -questions: General questions on FreeBSD - questioners and question-answerers - please! -bugs: Where bug reports should be sent. -SCSI: Mailing list for SCSI developers. -current: This list is for persons wishing to run FreeBSD-current - and carries announcements and discussions on current. This list - is *mandatory* if you run -current! -security: Information on issues dealing with system security. -platforms: Deals with ports to non-Intel platforms -ports: Discussion of /usr/ports/??? -fs: Discussion of FreeBSD Filesystems -hardware: Discussion on hardware requirements for FreeBSD. - -The FreeBSD-commit list has been broken up into groups dealing with different -areas of interest. Please see the FreeBSD mailing list FAQ in: - - /usr/share/FAQ/mailing-list.FAQ - - -0.3: What are the various FreeBSD news groups? - -There are two newsgroups currently dedicated to FreeBSD: - -comp.unix.bsd.freebsd.announce: For announcements -comp.unix.bsd.freebsd.misc: General discussion - - -The following newsgroups may also be of interest to general BSD -enthusiasts: - -comp.unix.bsd: General BSD topics -comp.os.386bsd.*: Ongoing, active FreeBSD discussions - (probably only for a short time longer). - - - -1 Installation --------------- - -1.1: I want to install FreeBSD onto a SCSI disk that has more than - 1024 cylinders. How do I do it? - -This depends. If you don't have DOS (or another operating system) on -the system, you can just keep the drive in native mode and simply make -sure that your root partition is below 1024 so the BIOS can boot the -kernel from it. It you also have DOS/some other OS on the drive then -your best bet is to find out what parameters that it thinks you have -before installing FreeBSD. When FreeBSD's installation procedure -prompts you for these values, you should then enter them rather than -simply going with the defaults. - -There is a freely available utility distributed with FreeBSD called -`pfdisk' (located in the tools/dos-tools subdirectory) which can be used for -this purpose. - - -1.2: When I boot FreeBSD it says ``Missing Operating System''. - -See question 1.2. This is classically a case of FreeBSD and DOS or -some other OS conflicting over their ideas of disk geometry. You will -have to reinstall FreeBSD, but obeying the instructions given above -will almost always get you going. - -1.3: When I install the boot manager and try to boot FreeBSD for the - first time, it just comes back with the boot manager prompt again. - -This is another symptom of the problem described in 1.2. Your -BIOS geometry and FreeBSD geometry settings do not agree! If your -controller or BIOS supports cylinder translation (often marked -as ">1GB drive support"), try toggling its setting and reinstalling -FreeBSD. - -1.4: I have an IDE drive with lots of bad blocks on it and FreeBSD doesn't - seem to install properly. - -FreeBSD's bad block (bad144) handling is still not 100% (to put it -charitably) and it must unfortunately be said that if you've got an -IDE or ESDI drive with lots of bad blocks, then FreeBSD is probably -not for you! That said, it does work on thousands of IDE based -systems, so you'd do well to try it first before simply giving up. - -IDE drives are *supposed* to come with built-in bad-block remapping; -if you have documentation for your drive, you may want to see if this -feature has been disabled on your drive. However, ESDI, RLL, and -ST-506 drives normally do not do this. - -1.5: I have 32MB of memory, should I expect any special problems? - -No. FreeBSD 2.0 comes with bounce buffers which allows your bus -mastering controller access to greater than 16MB. - -1.6: Do I need to install the complete sources? - -In general, no. However, we would strongly recommend that you -install, at a minimum, the `base' source kit, which includes several -of the files mentioned here, and the `sys' (kernel) source kit, which -includes sources for the kernel. There is nothing in the system which -requires the presence of the sources to operate, however, except for -the kernel-configuration program config(8). With the exception of the -kernel sources, our build structure is set up so that you can -read-only mount the sources from elsewhere via NFS and still be able -to make new binaries. (Because of the kernel-source restriction, we -recommend that you not mount this on /usr/src directly, but rather in -some other location with appropriate symbolic links to duplicate the -top-level structure of the source tree.) - -Having the sources on-line and knowing how to build a system with them -will make it much easier for you to upgrade to future releases of -FreeBSD. - -1.7: DES encryption software can not be exported from the United - States. If I live outside the US, how can I encrypt passwords? - -If it is not absolutely imperative that you use DES style encryption, -you can use FreeBSD's default encryption for even _better_ security, -and with no export restrictions. FreeBSD 2.0's password default -scrambler is now MD5 based, and is more CPU-intensive to crack -with an automated password cracker than DES. - -Since the DES encryption algorithm cannot legally be exported from the US, -non-US users should not download this software (as part of the secrdist) -from US FTP sites. - -There is however a replacement libcrypt available, based on sources -written in Australia by David Burren. This code is now available on -some non-US FreeBSD mirror sites. Sources for the unencumbered -libcrypt, and binaries of the programs which use it, can be obtained -from the following FTP sites: - - South Africa: braae.ru.ac.za:/pub/FreeBSD/securedist/ - owl.und.ac.za (currently uncertain) - Iceland: ftp.veda.is:/pub/crypt/FreeBSD/ - -The non-US securedist can be used as a direct replacement for the -encumbered US securedist. This securedist package is installed the -same way as the US package (see installation notes for details). If -you are going to install DES encryption, you should do so as soon as -possible, before installing other software. - -Non-US users should please not download any encryption software from -the USA. This can get the maintainers of the sites from which the -software is downloaded into severe legal difficulties. - -A non-US distribution of Kerberos is also being developed, and current -versions can generally be obtained by anonymous FTP from -braae.ru.ac.za. - -There is a mailing list for the discussion of non-US encryption -software. For more information, send an email message with a single -line saying ``help'' in the body of your message to -<majordomo@braae.ru.ac.za>. - - - -2 Hardware compatibility ------------------------- - -2.1: What kind of hard drives does FreeBSD run on? - -FreeBSD supports ST-506 (sometimes called ``MFM''), RLL, and ESDI -drives, which are usually connected to WD-1002, WD-1003, or WD-1006 -controllers (although clones should also work). - -FreeBSD also supports IDE and SCSI hard drives. - -2.2: What SCSI controllers are supported? - -FreeBSD supports the following SCSI controllers: - -Adaptec AH-154x Series <ISA> - AH-174x Series <EISA> - AH-152x Series <ISA> - Sound Blaster SCSI (AH-152x compat) <ISA> - AH-2742/2842 Series <ISA/EISA> - AH-2820/2822/2825 Series <VLB> -Buslogic BT-445 Series <VLB> (but see section 1.5) - BT-545 Series <ISA> - BT-742 Series <EISA> - BT-747 Series <EISA> - BT-964 Series <PCI> -Future Domain TMC-950 Series <ISA> -PCI Generic NCR 53C810 based controllers <PCI> -ProAudioSpectrum Zilog 5380 based controllers <ISA> -Seagate ST-01/02 Series <ISA> -UltraStor UH-14f Series <ISA> - UH-24f Series <EISA> - UH-34f Series <VLB> - -<2.X-Current Only> -Western Digital WD7000 <ISA> <No scatter/gather> -Adaptec AH-294x and aic7870 MB controllers <PCI> -ProAudioSpectrum Trantor 130 based controllers <ISA> - -2.3: What CD-ROM drives are supported by FreeBSD? - -Any SCSI drive connected to a supported controller. -Mitsumi LU002(8bit), LU005(16bit) and FX001D(16bit 2x Speed). - -<2.X-Current> -Sound Blaster Non-SCSI CD-ROM - -FreeBSD does not support any of the ``IDE'' CD-ROM interfaces. -All non-SCSI cards are known to be extremely slow compared to SCSI -drives. - -2.4: What multi-port serial cards are supported by FreeBSD? - -AST/4 -ARNET/8 -BOCA 4/8/16 port cards. -RISCom/8 - -<2.X-Current> -Cyclades 8/16 port <Alpha> - -Some unnamed clone cards have also been known to work,, especially those -that claim to be AST compatible. -Check the sio(4) man page to get more information on configuring such -cards. - - -2.5: Does FreeBSD support the AHA-2742/2842 SCSI adapters from Adaptec? - -Yes, though portions of the sources are currently GPL'd (that is to say, -distributed under the GNU Public License), so be aware of the fact should -you wish to distribute kernel binaries compiled with it - you MUST also -provide the sources to the driver with the kernel image to stay legal -with the GPL! This is easily enough done by simply including the contents -of /usr/src/sys/gnu/{aic7770,misc} on whatever media you distribute the -kernel. - -We are working to get the GPL restriction removed, but for now you should -at least be aware of it. - - -2.6: I have a Mumbleco bus mouse. Is it supported and if so, how do I set - it up for XFree86? - -FreeBSD supports the Logitech and ATI Inport bus mice. You need to -add the following line to the kernel config file and recompile for the -Logitech and ATI mice: - - device mse0 at isa? port 0x23c tty irq6 vector mseintr - - -2.7: I have a PS/2 mouse (`keyboard' mouse) [Alternatively: I have a - laptop with a track-ball mouse]. How do I use it? - - - -2.8: What types of tape drives are supported under FreeBSD? - -FreeBSD supports SCSI, QIC-02 and QIC-40/80 (Floppy based) tape -drives. This includes 8-mm (aka Exabyte) and DAT drives. - - -2.9: What sound cards are supported by FreeBSD? - -FreeBSD supports the SoundBlaster, SoundBlaster Pro, Pro Audio -Spectrum 16, AdLib and Gravis UltraSound sound cards. There is also -limited support for MPU-401 and compatible MIDI cards. The -SoundBlaster 16 and SoundBlaster 16 ASP cards are not yet supported. -NOTE: This is only for sound! This driver does not support CD-ROMs, -SCSI or joysticks on these cards. - - -2.10: What network cards does FreeBSD support? - -There is support for the following cards: - -`ed' driver: - NE2000 and 1000 - WD/SMC 8003, 8013 and Elite Ultra (8216) - 3Com 3c503 - And clones of the above - -`de' driver: - DEC and compatible PCI controllers. - -`le' driver: - DEC LANCE ethernet based controllers. - -`ie' driver: - AT&T EN100/StarLAN 10 - 3Com 3c507 - -`is' driver: - Isolan AT 4141-0 - Isolink 4110 - -`ep' driver: - 3com 3c509 (*) - -`el' driver: - 3com 3c501 (*) - -`ze' driver: - IBM PCMCIA credit card adapter - -`lnc' driver: - Unknown Lance based (*) - -<2.X-Current> - -`cx' driver - Cronyx/Sigma multiport Sync/Async (Cisco and PPP framing) - -`zp' driver - 3Com PCMCIA Etherlink III - -Note: Drivers marked with (*) are known to have problems. - -Note: We also support TCP/IP over parallel lines. At this point we are - incompatiable with other versions, but we hope to correct this in - the near future. - -2.11: I have a 386/486sx/486SLC machine without a math co-processor. - Will this cause me any problems? - -Generally no, but there are circumstances where you will take a hit, -either in performance or accuracy of the math emulation code (see -section 4.1). In particular, drawing arcs in X will be VERY slow. It -is highly recommended that you lay out the $50 or so for a math -co-processor; it's well worth it. NOTE: Some math co-processors are -better than others. It pains us to say it, but nobody ever got fired -for buying Intel. Unless you're sure it works with FreeBSD, beware of -clones. - -2.12: What other devices does 2.X support? - -Here is a listing of drivers that do not fit into any of the above areas. - -b004.c Driver for B004 compatiable Transputer boards -ctx.c Driver for CORTEX-I Frame grabber -gpib.c Driver for National Instruments AT-GPIB and AT-GPIB/TNT boards -pcaudio.c Driver for PC speakers to allow the playing of audio files -tw.c Driver for the X-10 POWERHOUSE - -<2.X-Current> -spigot.c Driver for the Creative Labs Video Spigot -gsc.c Driver for the Genuis GS-4500 Hand scanner -joy.c Driver for a joystick - -2.13: I am about to buy a new machine to run FreeBSD on and - want an idea of what other people are running. Is there list - of other systems anywhere? - -Yes. Please look at the file Systems.FAQ. This file -is a listing of hardware that people are running in their machines. -Please note, this is a raw listing of equipment that other users -have sent in, and does not constitute any kind of endorsement by the -FreeBSD Project. - -2.14: I have a lap-top with power management. Can FreeBSD take advantage - of this? - -Yes it can on certain machines. Please look in the LINT kernel config -file under APM. - - - -3 Commercial Applications -------------------------- - -Note: This section is still very sparse, though we're hoping, of -course, that companies will add to it! :) The FreeBSD group has no -financial interest in any of the companies listed here but simply -lists them as a public service (and feels that commercial interest in -FreeBSD can have very positive effects on FreeBSD's long-term -viability). We encourage commercial software vendors to send their -entries here for inclusion. - - -3.1: Where can I get Motif for FreeBSD? - -You can purchase Motif 1.2.3 for FreeBSD (SWiM) from the ACC Bookstore, -P.O. Box 3364, Westport CT. 06880. 1-800-546-7274 or FAX: 1-203-454-2582 - -This software works flawlessly for for FreeBSD 1.1.5 but has shown -one problem with 2.0 in that the "uil" program core dumps. This is -apparently because of the way uil is installed, and it's quite possible -that ACC will have a fixed version by the time you read this. No -other compatibility problems with the programs or libraries have been -found, and ACC can hardly be blamed for failing to work perfectly with -a brand-new release they haven't even seen yet! :) - - -3.2: Are there any commercial X servers for some of the high-end - graphics cards like the Matrox or #9 I-128, or offering 8/16/24 - bit deep pallettes? - -Yes, X Inside Incorporated sells their Accelerated-X product for -FreeBSD and other Intel based systems. - -This high performance X Server offers easy configuration, support -for multiple concurrent video boards and is distributed in binary -form only. - -Price is $99.50 (promotional price for Linux/FreeBSD version) for -the 1.1 version, which is available now. - -This product is for FreeBSD 1.1 and runs under 2.0 with the FreeBSD 1.1 -compatibility libs (`compat1xdist'). - -More info: URL http://www.xinside.com/ - or URL ftp://ftp.xinside.com/accelx/1.1/prodinfo.txt - or email info@xinside.com - or phone +1(303)384-9999 - - -3.3: Any other applications I might be interested in? - -RenderMorphics, Ltd. sells a high-speed 3D rendering package for -FreeBSD called "Reality Lab" (tm). Send email to info@render.com -or call: +44(0)71-251-4411 / FAX: +44(0)71-251-0939 - -This package is also for FreeBSD 1.1.5 but has been tested and shown -to run under FreeBSD 2.0 with the compat1xdist installed. - -Thanks must be extended to all of these companies for showing enough faith -in FreeBSD to port their products to it. While we get no direct benefit -from the sales of these products, the indirect benefits of FreeBSD -proving itself to be a successful platform for such commercial interests -will be immense! We wish these companies every measure of success, and -can only hope that others are encouraged to follow suit. - - -4 User Applications -------------------- - -4.1: I want to run X, how do I go about it? - -First, get the XFree86 distribution of X11R6 from XFree86.cdrom.com. -The version you want for FreeBSD 2.X and later is XFree86 3.1.1. Follow -the instructions for installation carefully. You may then wish to read -the documentation for the ConfigXF86 tool, which assists you in -configuring XFree86 for your particular graphics card/mouse/etc. - -You may also wish to investigate the Xaccel server, which is available -at a very reasonable price. See section 3.2 for more details. - -4.2: I've been trying to run ghostscript on a 386 (or 486sx) with no - math co-processor and I keep getting errors. What's up? - -You will need to add the alternate math emulator to your kernel, you do this -by adding the following to your kernel config file and it will be compiled in. - -options GPL_MATH_EMULATE - -NOTE: You will need to remove the MATH_EMULATE option when you do this. - - -4.2: I want all this neat software, but I haven't got the space or - CPU power to compile it all myself. Is there any way of getting - binaries? - -Yes. We support the concept of a `package', which is essentially a -gzipped binary distribution with a little extra intelligence embedded -in it for doing any custom installation work required. Packages can -also be installed or deinstalled again easily without having to know -the gory details. CDROM people will have a packages/ directory on -their CD, others can get the currently available packages from: - - ftp://ftp.FreeBSD.ORG/pub/FreeBSD/packages - -Note that all ports may not be available as packages, and that new -packages are constantly being added. It is always a good idea to -check periodically to see which packages are available. A README file -in the packages directory provides more details on the care and -feeding of the package software, so no explicit details will be given -here. - - - - -5 Miscellaneous Questions ----------------- - -5.1: I've heard of something called FreeBSD-current. How do I run it, and - where can I get more information? - -Read the file /usr/src/share/FAQ/current-policy.FAQ, -it will tell you all you need to know. - - -5.2: What is this thing called `sup', and how do I use it? - -SUP stands for Software Update Protocol, and was developed by CMU for -keeping their development trees in sync. We use it to keep remote -sites in sync with our central development sources. - -Unless you have direct internet connectivity, and don't care too much -about the cost/duration of the sessions, you shouldn't use sup. For -those "low/expensive-bandwidth" applications, we have developed CTM, -see 5.6 for more about that. - -To use it, you need to have direct internet connectivity (not just -mail or news). First, pick up the sup.tgz package from: - - ftp://ftp.FreeBSD.ORG/pub/FreeBSD/packages/sup.tgz - -Second, read the file /usr/src/share/FAQ/sup.FAQ. - -This file describes how to setup sup on your machine. You may also -want to look at /usr/src/share/FAQ/extras/*.supfile, or you may grab updated -supfiles from: - - ftp://ftp.FreeBSD.ORG//pub/FreeBSD/FAQ/extras - -which are a set of supfiles for supping from FreeBSD.ORG. - - -5.3: How do I create customized installation disks that I can give - out to other people at my site? - -The entire process of creating installation disks and source and -binary archives is automated by various targets in -/usr/src/etc/Makefile. The information there should be enough to get -you started. - -5.4: How do I re-build my system without clobbering the existing - installed binaries? - -If you define the environment variable DESTDIR while running `make -world' or `make install', the newly-created binaries will be deposited -in a directory tree identical to the installed one, rooted at -${DESTDIR}. Some random combination of shared libraries modifications -and program rebuilds can cause this to fail in `make world', however. - - -5.5: When my system booted, it told me that ``(bus speed defaulted)''. - What does that mean? - -The Adaptec 1542 SCSI host adapters allow the user to configure their -bus access speed in software. Previous versions of the 1542 driver tried -to determine the fastest usable speed and set the adapter to that. We -found that this breaks some users' systems, so you now have to define -the ``TUNE_1542''' kernel configuration option in order to have this -take place. Using it on those systems where it works may make your -disks run faster, but on those systems where it doesn't, your data could -be corrupted. - -5.6: I would like to track changes to current and do not have net access. - Is there any way besides downloading the whole tree? - -Yes, you can use the CTM facility. Check out the ctm.FAQ file or - ftp://freefall.cdrom.com/pub/CTM/README -for more information. - -5.7: How do I split up large binary files into smaller 240k files - like the distribution does? - -Newer BSD based systems have a "-b" option to split that allows them to -split files on arbitary byte bondaries. - -Here is an example from /usr/src/Makefile. -bin-tarball: - (cd ${DISTDIR}; \ - tar cf - . \ - gzip --no-name -9 -c | \ - split -b 240640 - \ - ${RELEASEDIR}/tarballs/bindist/bin_tgz.) - - -<XXX> 5.8: I've had a couple of system panics and would like to be able - browse the system dumps. The normal kernel is stripped and - I don't want to run a bloated kernel. What can I do? - -5.9: I just got a Perl application and it's bombing looking for - *.ph. Where is it? - -There was a minor SNAFU in the 2.0-R bindist and they got left out. -If you have the source, you just have to do a "make install" from -/usr/src/gnu/usr.bin/perl/lib and everything will be fine. Or you -may ftp to phoenix-gw.gbdata.com and grab them from ~/pub/perl/libs.tar.gz. - -5.10: I've got this neato kernel extension I just know everyone will - will want. How do I get it included into the distribution? - -Please take a look at the FAQ for submiting code to FreeBSD at: - - ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FAQ/submitters.FAQ - -And thanks for the thought. - - -6 Kernel Configuration ----------------------- - -6.0: Ok, so how DO I compile my own kernel, anyway? - -Before you can compile a kernel, you need either the complete srcdist -or, at the minimum, the kerndist loaded on your system. This provides -the necessary sources for building the kernel, as we have a policy of -NOT shipping our kernels in linkable object form as most commercial -UNIX vendors do. Shipping the source takes a bit more space, but it also -means that you can refer to the actual kernel sources in case of difficulty -or to further your understanding of what's *actually* happening. - -Anyway, to answer the question, once you have the kerndist or srcdist -loaded, do this: - - 6.0.1: cd /usr/src/sys/i386/conf - 6.0.2: cp GENERIC MYKERNEL - 6.0.3: vi MYKERNEL - 6.0.4: config MYKERNEL - 6.0.5: cd ../../compile/MYKERNEL - 6.0.6: make all - 6.0.7: make install - 6.0.8: reboot - -Step 6.0.2 may not be necessary if you already have a kernel configuration -file from a previous release of FreeBSD 2.x. - simply bring your old one -over and check it carefully for any drivers that may have changed boot -syntax or been rendered obsolete. - -A good kernel config file to look into is LINT, which contains entries for -*all* possible kernel options and documents them fairly well. The GENERIC -kernel config file is used to build the initial release you probably loaded -(unless you upgraded in-place) and contains entries for the most common -configurations. It's a pretty good place to start from. - -If you don't need to make any changes to GENERIC, you can also skip step -6.0.3, where you customize the kernel for your configuration. Step 6.0.7 -should only be undertaken if step 6.0.6 succeeds. This will copy -the new kernel image to /kernel and BACK UP YOUR OLD ONE IN /kernel.old! -It's very important to remember this in case the new kernel fails to work -for some reason - you can still select /kernel.old at the boot prompt to -boot the old one. When you reboot, the new kernel will boot by default. - -If the compile in 6.0.6 falls over for some reason, then it's recommended -that you start from step 6.0.4 but substitute GENERIC for MYKERNEL. If you -can generate a GENERIC kernel, then it's likely something in your special -configuration file that's bad (or you've uncovered a bug!). If the build -of the GENERIC kernel does NOT succeed, then it's very likely that your -sources are somehow corrupted. - -Finally, if you need to see your original boot messages again to compile -a new kernel that's better tailored to your hardware, try the `dmesg' command. -It should print out all the boot-time messages printed by your old kernel, -some of which may be quite helpful in configuring the new one. - - -6.1: When I compile a kernel with multi-port serial code, it tells me - that only the first port is probed and the rest skipped due to - interrupt conflicts. How do I fix this? - -The problem here is that FreeBSD has code built-in to keep the kernel -from getting trashed due to hardware or software conflicts. The way -to fix this is to leave out the IRQ settings on other ports besides -the first. Here is a example: - -# -# Multiport high-speed serial line - 16550 UARTS -# -device sio2 at isa? port 0x2a0 tty irq 5 flags 0x501 vector siointr -device sio3 at isa? port 0x2a8 tty flags 0x501 vector siointr -device sio4 at isa? port 0x2b0 tty flags 0x501 vector siointr -device sio5 at isa? port 0x2b8 tty flags 0x501 vector siointr - - -6.2: FreeBSD is supposed to come with support for QIC-40/80 drives but - when I look, I can't find it. - -You need to uncomment the following line in the generic config file -(or add it to your config file), make the change to the fdc0 line shown, -and recompile. - -controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr flags 0x1 - ^^^^^^^^^ -disk fd0 at fdc0 drive 0 -disk fd1 at fdc0 drive 1 -#tape ft0 at fdc0 drive 2 -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You will have a device called /dev/ft0, which you can write to through -a special program to manage it called `ft' - see the man page on ft for -further details. Versions previous to -current also had some trouble dealing -wiht bad tape media; if you have trouble where ft seems to go back and forth -over the same spot, try grabbing the latest version of ft from /usr/src/sbin/ft -in current and try that. - - -6.3: Does FreeBSD support IPC primitives like those in System V? - -Yes, FreeBSD supports System V-style IPC. This includes shared -memory, messages and semaphores. You need to add the following lines -to your kernel config to enable them. - -options SYSVSHM -options "SHMMAXPGS=64" # 256Kb of sharable memory -options SYSVSEM # enable for semaphores -options SYSVMSG # enable for messaging - -Recompile and install. - - -6.4: Will FreeBSD ever support other architectures? - -Several different groups have expressed interest in working on -multi-architecture support for FreeBSD. If you are interested in -doing so, please contact the developers at -<FreeBSD-hackers@FreeBSD.ORG> for more information on our -strategy for porting. - - -6.5: I just wrote a device driver for a Foobar Systems, Inc. - Integrated Adaptive Gronkulator card. How do I get the - appropriate major numbers assigned? - -This depends on whether or not you plan on making the driver publicly -available. If you do, then please send us a copy of the driver source -code, plus the appropriate modifications to files.i386, a sample -configuration file entry, and the appropriate MAKEDEV code to create -any special files your device uses. If you do not, or are unable to -because of licensing restrictions, then character major number 32 and -block major number 8 have been reserved specifically for this purpose; -please use them. In any case, we'd appreciate hearing about your -driver on <FreeBSD-hackers@FreeBSD.ORG>. - - - -7 System Administration ------------------------ - -7.1: How do I add a user easily? I read the man page and am more confused - than ever! [Alternatively: I didn't read the man page, I never read - man pages! :-) ] - -Use the adduser command. - - -<XXX> 7.2: I'm trying to use my printer and keep running into problems. I tried - looking at /etc/printcap, but it's close to useless. Any ideas? - - - -8 Networking ------------- - - -8.2: I've heard that you can use a FreeBSD box as a dedicated network - router - is there any easy support for this? - -Internet standards and good engineering practice prohibit us from -providing packet forwarding by default in FreeBSD. You can enable -this support by adding `options GATEWAY' to your kernel configuration -file and recompiling. In most cases, you will also need to run a -routing process to tell other systems on your network about your -router; FreeBSD comes with the standard BSD routing daemon routed(8), -or for more complex situations you may want to try GateD (available by -FTP from gated.Cornell.edu) which supports FreeBSD as of 3_5Alpha7. - -It is our duty to warn you that, even when FreeBSD is configured in -this way, it does not completely comply with the Internet standard -requirements for routers; however, it comes close enough for ordinary -usage. - - -8.3: Does FreeBSD support SLIP and PPP? - -Yes. See the man pages for slattach(8) and/or pppd(8) if you're using -FreeBSD to connect to another site. If you're using FreeBSD as a -server for other machines, look at the man page for sliplogin(8). -You may also want to take a look at the slip FAQ in: - /usr/src/share/FAQ/Slip.FAQ - -8.4: How do I get my network set up? I don't see how to make my - /dev/ed0 device! - -In the Berkeley networking framework, network interfaces are only -directly accessible by kernel code. Please see the /etc/netstart file -and the manual pages for the various network programs mentioned there -for more information. If this leaves you totally confused, then you -should pick up a book describing network administration on another -BSD-related operating system; with few significant exceptions, -administering networking on FreeBSD is basically the same as on SunOS -4.0 or Ultrix. - -8.5: How do I get my 3C503 to use the other network port? - -Use `ifconfig ed0' to see whether the ALTPHYS flag is set, and then -use either `ifconfig ed0 altphys' if it was off, or `ifconfig ed0 --altphys' if it was on. - -8.6: I'm having problems with NFS to/from FreeBSD and my Wuffotronics - Workstation / generic NFS appliance, where should I look first? - -Certain PC network cards are better than others (to put it mildly) and -can sometimes cause problems with network intensive applications like -NFS. See /usr/src/share/FAQ/NFS.FAQ for more information on this -topic. - -8.8: I want to enable IP multicast support on my FreeBSD box, how do I do it? - [Alternatively: What the heck IS multicasting and what applications - make use of it?] - -Multicast host operations are fully supported in FreeBSD 2.0 by default. -If you want your box to run as a multicast router, you will need to load -the ip_mroute_mod loadable kernel module and run mrouted. - -For more information: - -Product Description Where ---------------- ----------------------- --------------------------------------- -faq.txt Mbone FAQ ftp.isi.edu:/mbone/faq.txt -imm/immserv IMage Multicast ftp.hawaii.edu:/paccom/imm.src.tar.Z - for jpg/gif images. -nv Network Video. ftp.parc.xerox.com: - /pub/net-reseach/exp/nv3.3alpha.tar.Z -vat LBL Visual Audio Tool. ftp.ee.lbl.gov: - /conferencing/vat/i386-vat.tar.Z -wb LBL White Board. ftp.ee.lbl.gov: - /conferencing/wb/i386-wb.tar.Z -mmcc MultiMedia Conference ftp.isi.edu: - Control program /confctrl/mmcc/mmcc-intel.tar.Z -rtpqual Tools for testing the ftp.psc.edu:/pub/net_tools/rtpqual.c - quality of RTP packets. -vat_nv_record Recording tools for vat ftp.sics.se:archive/vat_nv_record.tar.Z - and nv. - - - -9 Serial Communications ------------------------ - -This section answers common questions about serial communications with -FreeBSD. - -9.1: How do I tell if FreeBSD found my serial ports or modem cards? - -As the FreeBSD kernel boots, it will probe for the serial ports in -your system for which the kernel was configured. You can either watch -your system closely for the messages it prints or run the command - - dmesg | grep sio - -after your system's up and running. - -Here's some example output from the above command: - - sio0 at 0x3f8-0x3ff irq 4 on isa - sio0: type 16550A - sio1 at 0x2f8-0x2ff irq 3 on isa - sio1: type 16550A - -This shows two serial ports. The first is on irq 4, is using port -address 0x3f8, and has a 16550A-type UART chip. The second uses the -same kind of chip but is on irq 3 and is at port address 0x2f8. -Internal modem cards are treated just like serial ports---except that -they always have a modem ``attached'' to the port. - -The GENERIC kernel includes support for two serial ports using the -same irq and port address settings in the above example. If these -settings aren't right for your system, or if you've added modem cards -or have more serial ports than your kernel is configured for, just -reconfigure your kernel. See section 7 of the FAQ for more details. - -9.2: How do I access the serial ports once FreeBSD is running? - -The third serial port, sio2 (known as COM3 in DOS), is on /dev/tty02 -for directly-connected devices, on /dev/cuaa2 for dial-out devices, -and on /dev/ttyd2 for dial-in devices. What's the difference between -these three classes of devices? - -You use ttyXX for directly-connected or hardwired devices, like -printers or terminals. - -In place of ttyXX, you can use the pair of devices cuaaX and ttydX. -You use ttydX for dial-ins. The ttydX device acts like the ttyXX -device, but it also uses the modem control lines. When opening -/dev/ttydX in blocking mode, a process will wait for the corresponding -cuaaX device to become inactive, and then wait for the carrier detect -line to go active. When you open the cuaaX device, it makes sure the -serial port isn't already in use by the ttydX device. If the port's -available, it ``steals'' it from the ttydX device. Also, the cuaaX -device doesn't care about carrier detect. With this scheme and an -auto-answer modem, you can have remote users log in and you can still -dialout with the same modem and the system will take care of all the -conflicts. - -9.3: How do I configure the kernel for my multiport serial card? - -Again, the section on kernel configuration provides information about -configuring your kernel. For a multiport serial card, place an sio -line for each serial port on the card in the kernel configuration -file. But place the irq and vector specifiers on only one of the -entries. All of the ports on the card should share one irq. For -consistency, use the last serial port to specify the irq. Also, -specify the COM_MULTIPORT option. - -The following example is for an AST 4-port serial card on irq 7: - - options "COM_MULTIPORT" - device sio4 at isa? port 0x2a0 tty flags 0x781 - device sio5 at isa? port 0x2a8 tty flags 0x781 - device sio6 at isa? port 0x2b0 tty flags 0x781 - device sio7 at isa? port 0x2b8 tty flags 0x781 irq 7 vector siointr - -The flags indicate that the master port has minor number 7 (0x700), -diagnostics enabled during probe (0x080), and all the ports share an -irq (0x001). - -9.4: I have two multiport serial cards that can share irqs. Can - FreeBSD handle this? - -Not yet. You'll have to use a different irq for each card. - -9.5: What's the difference between tty01, ttyi01, and ttyl01? Or, - how can I set the default serial parameters for a port? - -The ttyXX (or cuaaX or ttydX) device is the regular device you'll want -to open for your applications. When a process opens the device, it'll -have a default set of terminal I/O settings. You can see these -settings with the command - - stty -a -f /dev/tty01 - -When you change the settings to this device, the settings are in -effect until the device is closed. When it's reopened, it goes back -to the default set. To make changes to the default set, you can open -and adjust the settings of the ``initial state'' device. For example, -to turn on CLOCAL mode, 8 bits, and XON/XOFF flow control by default -for tty05, do: - - stty -f /dev/ttyi05 clocal cs8 ixon ixoff - -A good place to do this is in /etc/rc.serial. Now, an application -will have these settings by default when it opens tty05. It can still -change these settings to its liking, though. - -You can also prevent certain settings from being changed by an -application by making adjustments to the ``lock state'' device. For -example, to lock the speed of tty05 to 57600 bps, do - - stty -f /dev/ttyl05 57600 - -Now, an application that opens tty05 and tries to change the speed of -the port will be stuck with 57600 bps. - -Naturally, you should make the initial state and lock state devices -writable only by root. The MAKEDEV script does NOT do this when it -creates the device entries. - -9.6: How can I enable dialup logins on my modem? - -So you want to become an Internet service provider, eh? First, you'll -need one or more modems that can autoanswer. Your modem will need to -assert carrier-detect when it detects a carrier and not assert it all -the time. It will need to hang up the phone and reset itself when the -data terminal ready (DTR) line goes from on to off. It should -probably use RTS/CTS flow control or no local flow control at all. -Finally, it must use a constant speed between the computer and itself, -but (to be nice to your callers) it should negotiate a speed between -itself and the remote modem. - -For many Hayes command-set--compatible modems, this command will -make these settings and store them in nonvolatile memory: - - AT &C1 &D3 &K3 &Q6 S0=1 &W - -See 9.10 below for information on how to make these settings without -resorting to an MS-DOS terminal program. - -Next, make an entry in /etc/ttys for the modem. This file lists all -the ports on which the operating system will await logins. Add a line -that looks something like this: - - ttyd1 "/usr/libexec/getty std.57600" dialup on insecure - -This line indicates that the second serial port (/dev/ttyd1) has a -modem connected running at 57600 bps and no parity (std.57600, which -comes from the file /etc/gettytab). The terminal type for this port -is ``dialup.'' The port is ``on'' and is ``insecure''---meaning root -logins on the port aren't allowed. For dialin ports like this one, -use the ttydX entry. - -It's common practice to use ``dialup'' as the terminal type. Many -users set up in their .profile or .login files a prompt for the actual -terminal type if the starting type is dialup. The example shows the -port as insecure. To become root on this port, you have to login as a -regular user, then ``su'' to root. If you use ``secure'' then root -can login in directly. - -After making modifications to /etc/ttys, you need to send a hangup or -HUP signal to the init process: - - kill -1 1 - -This forces the init process to reread /etc/ttys. The init process -will then start getty processes on all ``on'' ports. You can find out -if logins are available for your port by typing - - ps -ax | grep '[t]tyd1' - -You should see something like: - - 747 ?? I 0:00.04 /usr/libexec/getty std.57600 ttyd1 - -9.7: How can I make my spare computer a dumb terminal connected to my - FreeBSD box? - -If you're using another computer as a terminal into your FreeBSD -system, get a null modem cable to go between the two serial ports. If -you're using an actual terminal, see its accompanying instructions. - -Then, modify /etc/ttys, like above. For example, if you're hooking up -a WYSE-50 terminal to the fifth serial port, use an entry like this: - - tty04 "/usr/libexec/getty std.38400" wyse50 on secure - -This example shows that the port on /dev/tty04 has a wyse50 terminal -connected at 38400 bps with no parity (std.38400 from /etc/gettytab) -and root logins are allowed (secure). For directly-connected -terminals, use the ttyXX entry. - -9.8: Why can't I run tip or cu? - -On your system, the programs tip and cu are probably executable only -by uucp and group dialer. You can use the group dialer to control who -has access to your modem or remote systems. Just add yourself to -group dialer. - -Alternatively, you can let everyone on your system run tip and cu by -typing: - - chmod 4511 /usr/bin/tip - -You don't have to run this command for cu, since cu is just a hard -link to tip. - -9.9: My stock Hayes modem isn't supported---what should I do? - -Actually, the man page for tip is out of date. There is a generic -Hayes dialer already built in. Just use ``at=hayes'' in your -/etc/remote file. - -The Hayes driver isn't smart enough to recognize some of the advanced -features of newer modems---messages like BUSY, NO DIALTONE, or CONNECT -115200 will just confuse it. You should turn those messages off when -you use tip (using ATX0&W). - -Also, the dial timeout for tip is 60 seconds. Your modem should use -something less, or else tip will think there's a communication -problem. Try ATS7=45&W. - -9.10: How am I expected to enter these AT commands without - resorting to some DOS-based terminal program? - -Make what's called a ``direct'' entry in your /etc/remote file. For -example, if your modem's hooked up to the first serial port, -/dev/cuaa0, then put in the following line: - - cuaa0:dv=/dev/cuaa0:br#19200:pa=none - -Use the highest bps rate your modem supports in the br capability. -Then, type ``tip cuaa0'' and you'll be connected to your modem. - -If there is no /dev/cuaa0 on your system, do this: - - cd /dev - MAKEDEV cuaa0 - -9.11: Why doesn't the @ sign for the phone number capability work? - -The @ sign in the pn capability tells tip to look in /etc/phones for a -phone number. But the @ sign is also a special character in -capability files like /etc/remote. Escape it with a backslash: -``pn=\@''. - -9.12: How can I dial a phone number on the command line? - -Put what's called a ``generic'' entry in your /etc/remote file. For -example: - - tip115200|Dial any phone number at 115200 bps:\ - :dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du: - tip57600|Dial any phone number at 57600 bps:\ - :dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du: - -Then you can things like ``tip -115200 5551234''. If you prefer cu -over tip, use a generic cu entry: - - cu115200|Use cu to dial any number at 115200bps:\ - :dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du: - -and type ``cu 5551234 -s 115200''. - -9.13: Great---but how can I do that without having to specify the bps - rate on the command line? - -Put in an entry for tip1200 or cu1200, but go ahead and use whatever -bps rate is appropriate with the br capability. tip thinks a good -default is 1200 bps which is why it looks for a ``tip1200'' entry. -You don't have to use 1200 bps, though. - -9.14: I want separate entries for various hosts I access through a - terminal server, but I don't want to type ``CONNECT <host>'' - each time once I'm connected. Can tip do that for me? - -Yes. Use the cm capability. For example, these entries in -/etc/remote: - - pain|pain.deep13.com|Forrester's machine:\ - :cm=CONNECT pain\n:tc=deep13: - muffin|muffin.deep13.com|Frank's machine:\ - :cm=CONNECT muffin\n:tc=deep13: - deep13:Gizmonics Institute terminal server:\ - :dv=/dev/cuaa2:br#38400:at=hayes:du:pa=none:pn=5551234: - -will let you type ``tip pain'' or ``tip muffin'' to connect to the -hosts pain or muffin; and ``tip deep13'' to get to the terminal -server. - -9.15: My university has 42 billion students but only 4 modem lines. - Can tip automatically try each line? - -Sure. Make an entry for your university in /etc/remote and use \@ for -the pn capability: - - big-university:\ - :pn=\@:tc=dialout - dialout:\ - :dv=/dev/cuaa3:br#9600:at=courier:du:pa=none: - -Then, list the phone numbers for the university in /etc/phones: - - big-university 5551111 - big-university 5551112 - big-university 5551113 - big-university 5551114 - -tip will try each one in the listed order, then give up. If you want -to keep retrying, run tip in a while loop. - -9.16: How come I have to hit CTRL+P twice to send CTRL+P once? - -CTRL+P is the default ``force'' character, used to tell tip that the -next character is literal data. You can set the force character to -any other character with the ~s escape, which means ``set a -variable.'' - -Type ``~sforce=<single-char>'' followed by a newline. <single-char> -is any single character. If you leave out <single-char>, then the -force character is the nul character, which you can get by typing -CTRL+2 or CTRL+SPACE. A pretty good value for <single-char> is -SHIFT+CTRL+6, which I've seen only used on some terminal servers. - -You can have the force character be whatever you want by specifying -the following in your $HOME/.tiprc file: - - force=<single-char> - -9.17: Suddenly everything I type is all UPPER CASE. What gives? - -You must've pressed CTRL+A, tip's ``raise character,'' specially -designed for people with broken caps-lock keys. Use ~s as above and -set the variable ``raisechar'' to something reasonable. In fact, you -can set it to the same as the force character, if you never expect to -use either of these features. - -Here's a sample .tiprc file perfect for Emacs users who need to type -CTRL+2 and CTRL+A a lot: - - force=^^ - raisechar=^^ - -The ^^ is SHIFT+CTRL+6. - -9.18: How can I do file transfers with tip? - -If you're talking to another UNIX system, you can send and receive -files with ~p (put) and ~t (take). These commands run ``cat'' and -``echo'' on the remote system to accept and send files. The syntax -is: - - ~p <local-file> [<remote-file>] - ~t <remote-file> [<local-file>] - -There's no error checking, so you probably should use another -protocol, like zmodem. - -9.19: Okay, how can I run zmodem with tip? - -To receive files, start the sending program on the remote end. Then, -type ``~C rz'' to begin receiving them locally. - -To send files, start the receiving program on the remote end. Then, -type ``~C sz <files>'' to send them to the remote system. - - - -NOTE: Anyone wishing to submit a FAQ entry on how to get tip and cu working - would have it much appreciated! We all use Kermit over here! :-) - ------------------------------------------------------------------------------ -If you see a problem with this FAQ, or wish to submit an entry, please -mail us at <FreeBSD-FAQ@FreeBSD.ORG>. We appreciate your -feedback, and cannot make this a better FAQ without your help! - - - FreeBSD Core Team - ------------------------------------------------------------------------------ - -ACKNOWLEDGMENTS: - -Ollivier Robert - FreeBSD FAQ maintenance man -Gary Clark II - Ex-FreeBSD FAQ maintenance man -Jordan Hubbard - Janitorial services (I don't do windows) -Garrett Wollman - Networking and formatting -Robert Oliver, Jr. - Ideas and dumb questions (That made me think) -Jim Lowe - Multicast information -The FreeBSD Team - Kvetching, moaning, submitting data - -And to any others we've forgotten, apologies and heartfelt thanks! - diff --git a/share/FAQ/Text/HW.TROUBLE b/share/FAQ/Text/HW.TROUBLE deleted file mode 100644 index 86e3e42931f5..000000000000 --- a/share/FAQ/Text/HW.TROUBLE +++ /dev/null @@ -1,58 +0,0 @@ -$Id: HW.TROUBLE,v 1.3 1995/03/01 06:43:12 phk Exp $ - -This file lists hardware, which doesn't do what it should do. - -Due to the nature of FreeBSD, we do not have the resources to test all -possible kinds of hardware. We do however every now and then find, buy -or hear about hardware which doesn't work with FreeBSD or in general. - -This is that list. - -To be added to this list, a piece of hardware has to: - A: not do what it claims. -or - B: not do what common sense would expect it to. - -Only if performance claims are wildly of the mark will it be listed here. - -All entries must have a date and a mail-address associated with them, to -reflect when and by whom they were added. -For multifunctional devices, please indicate if other parts of the device -work OK, or are untested. -For mutual incompabilities, list both devices. -For SCSI and IDE-devices, list the string seen on boot of FreeBSD, if -possible, and trade name. -Infer format from other entries, Keep sorted by first line. - -Thankyou. - ---- -Controller, Data Technology DTC2280, "PC/AT Super I/O Card" -IDE interface can be set to secondary address, but doesn't work there. Suspect -Interrupt isn't moved along. Works fine on primary address. Other parts of -card not tested. -19940828 phk@freefall.cdrom.com ---- -IDE-disk, <WDC AC2540H>, "Western Digital Caviar 2540" -IDE-disk, <Maxtor 7345 AT>, "Maxtor 7345" -Cannot coexist on the same IDE-controller. -Jumpers not exhaustively experimented with, as neither of the companies -make sufficient information available. Disk works fine when alone on -IDE-controller. -19940828 phk@freefall.cdrom.com ---- -IDE-disk, <AC31000> "Western Digital Caviar 31000" -IDE-disk, <ST3550A> "Seagate ST3550A" -Western Digital AC31000 (Caviar 31000) 1080 meg IDE drive will not -co-exist with a Seagate ST3550A. -The Seagate as master causes a constant drive light and system lockup, -The WD will work fine alone or as master, but the Seagate is inaccessable -if configured as slave in this config. -19950221 jbryant@server.iadfw.net - -On Packard Bell computers with a BIOS Reference ID of less than 25, Packard -Bell will replace the BIOS at no charge. I waited, I got the bios, popped -the case, popped the chip, put in the new, and plugged in the drives. It -works. WD as master, seagate as slave. -19950228 jbryant@server.iadfw.net ---- diff --git a/share/FAQ/Text/MIRROR.SITES b/share/FAQ/Text/MIRROR.SITES deleted file mode 100644 index 96ed2ec289b9..000000000000 --- a/share/FAQ/Text/MIRROR.SITES +++ /dev/null @@ -1,145 +0,0 @@ - Mirror Sites - For FreeBSD 2.0 and later - -$Id: MIRROR.SITES,v 1.16 1995/08/05 02:04:18 jkh Exp $ - -The latest versions of FreeBSD (2.0 or later) are being mirrored at the -following locations: - -Country Site and Maintainer -======= ========================================================= -Australia ftp://ftp.physics.usyd.edu.au/FreeBSD - <dawes@xfree86.org> - -Australia ftp://minnie.cs.adfa.oz.au/FreeBSD - <wkt@dolphin.cs.adfa.oz.au> - -Canada ftp://ftp.synapse.net/contrib/FreeBSD - <evanc@synapse.net> - -Finland ftp://nic.funet.fi/pub/unix/FreeBSD - <count@nic.funet.fi> - -France ftp://ftp.ibp.fr/pub/FreeBSD - <Remy.Card@ibp.fr> - -Germany ftp://ftp.fb9dv.uni-duisburg.de/pub/unix/FreeBSD - <ftp@ftp.fb9dv.uni-duisburg.de> - -Germany ftp://gil.physik.rwth-aachen.de/pub/FreeBSD - <kuku@gil.physik.rwth-aachen.de> - -Germany ftp://ftp.uni-paderborn.de/freebsd - <ftp@uni-paderborn.de> - -Germany ftp://ftp.leo.org/pub/comp/os/bsd/FreeBSD - <bsd@leo.org> - -Germany ftp://ftp.tu-dresden.de/pub/soft/unix/bsd/FreeBSD - <pdsowner@rcs1.urz.tu-dresden.de> - -Ireland ftp://ftp.internet-eireann.ie/pub/FreeBSD - <ftpadmin@internet-eireann.ie> - -Israel ftp://orgchem.weizmann.ac.il/pub/FreeBSD - <serg@klara.weizmann.ac.il> - -Hong Kong ftp://ftp.hk.super.net/pub/FreeBSD - <ftp-admin@HK.Super.NET> - -Korea ftp://ftp.cau.ac.kr/pub/FreeBSD - <ftpadm@ftp.cau.ac.kr> - -Netherlands ftp://ftp.nl.net/pub/os/FreeBSD - <archive@nl.net> - -Russia ftp://ftp.kiae.su/FreeBSD - <ftp@ftp.kiae.su> - -Sweden ftp://ftp.luth.se/pub/FreeBSD - <ragge@ludd.luth.se> - -Taiwan ftp://NCTUCCCA.edu.tw/Operating-Systems/FreeBSD - <freebsd@NCTUCCCA.edu.tw> - -Taiwan ftp://netbsd.csie.nctu.edu.tw/pub/FreeBSD - <ftp@netbsd.csie.nctu.edu.tw> - -Thailand ftp://ftp.nectec.or.th/pub/FreeBSD - <ftpadmin@ftp.nectec.or.th> - -USA ftp://gatekeeper.dec.com/pub/BSD/FreeBSD - <hubbard@gatekeeper.dec.com> - -USA ftp://ftp.cybernetics.net/pub/FreeBSD - <michael@Cybernetics.NET> - -USA ftp://ftp.neosoft.com/systems/FreeBSD - <smace@NeoSoft.COM> - -USA ftp://kryten.atinc.com/pub/FreeBSD - <jmb@kryten.atinc.com> - -USA ftp://ftp.dataplex.net/pub/FreeBSD - <rkw@dataplex.net> - -USA ftp://ftp.cps.cmich.edu/pub/ftp.freebsd.org - <ftpadmin@cps.cmich.edu> - -USA ftp://ftp.cslab.vt.edu/pub/FreeBSD - <ftp@ftp.cslab.vt.edu> - -Japan ftp://ftp.tokyonet.ad.jp/pub/FreeBSD - <ftpadmin@TokyoNet.AD.JP> - -Japan ftp://ftp.tut.ac.jp/FreeBSD - Ashida Hiroyuki <ashida@ftp.tut.ac.jp> - -Japan ftp://ftp.sra.co.jp/pub/os/FreeBSD - <ftp-admin@sra.co.jp> - -Japan ftp://ftp.ee.uec.ac.jp/pub/os/mirror/ftp.freebsd.org - <ftp-admin@ftp.ee.uec.ac.jp> - -Japan ftp://ftp.mei.co.jp/free/PC-UNIX/FreeBSD - TANIGUCHI Syuuhei <tanig@isl.mei.co.jp> - -Japan ftp://ftp.waseda.ac.jp/pub/FreeBSD - <ftp-admin@waseda.ac.jp> - -Japan ftp://ftp.pu-toyama.ac.jp/pub/FreeBSD - Yoshihiko USUI <usui@pu-toyama.ac.jp> - -Japan ftp://ftpsv1.u-aizu.ac.jp/pub/os/FreeBSD - <ftp-admin@u-aizu.ac.jp> - -UK ftp://src.doc.ic.ac.uk/packages/unix/FreeBSD - <wizards@doc.ic.ac.uk> - -UK ftp://unix.hensa.ac.uk/pub/walnut.creek/FreeBSD - <archive-admin@unix.hensa.ac.uk> - -UK ftp://ftp.demon.co.uk/pub/BSD/FreeBSD - <uploads@demon.net> - ---- - -The latest versions of export-restricted code for FreeBSD (2.0C or later) -(eBones and secure) are being made available at the following locations. - -If you are outside the U.S. or Canada, please get secure (DES) and -eBones (Kerberos) from one of the following foreign distribution sites: - -Country Site and Maintainer -======= ======================================================== -South Africa ftp://skeleton.mikom.csir.co.za/pub/FreeBSD - Mark Murray <mark@grondar.za> - -South Africa ftp://storm.sea.uct.ac.za/pub/FreeBSD - Shaun Courtney <ftp@storm.sea.uct.ac.za> - -Brazil ftp://ftp.iqm.unicamp.br/pub/FreeBSD - Pedro A M Vazquez <vazquez@iqm.unicamp.br> - -Finland ftp://nic.funet.fi/pub/unix/FreeBSD/eurocrypt - <count@nic.funet.fi> diff --git a/share/FAQ/Text/README b/share/FAQ/Text/README deleted file mode 100644 index 2e7293bb07ed..000000000000 --- a/share/FAQ/Text/README +++ /dev/null @@ -1,104 +0,0 @@ - ----------------------------------------- - FreeBSD 2.0.5 --- RELEASE Version , , - ----------------------------------------- /( )` - \ \___ / | -Welcome to the 2.0.5 release of FreeBSD! 2.0.5 is /- _ `-/ ' -an interim release of FreeBSD, filling a much needed (/\/ \ \ /\ -gap during the period between 2.0R (which was / / | ` \ -released in Nov 94) and 2.1R, which will be O O ) / | -released in late July of '95. FreeBSD 2.0.5 `-^--'`< ' -contains many substantial improvements from 2.0R, (_.) _ ) / -not least of which is greater stability (by `.___/` / -a considerable margin), dozens of new `-----' / -features and a greatly enhanced <----. __ / __ \ -installation program. See the release <----|====O)))==) \) /==== -notes for more details on what's new in <----' `--' `.__,' \ -FreeBSD 2.0.5! | | - \ / /\ - ______( (_ / \______/ - ,' ,-----' | - `--{__________) - - -What is FreeBSD? FreeBSD is an operating system based on 4.4 BSD Lite -for Intel, AMD, Cyrix or NexGen "x86" based PC hardware. It works -with a very wide variety of PC peripherals and configurations and can -be used for everything from software development to Internet Service -Provision; the busiest site on the Internet, ftp.cdrom.com, is a -FreeBSD machine! - -This release of FreeBSD contains everything you need to run such a -system, plus full source code for everything. With the source -distribution installed you can literally recompile the entire system -from scratch with one command, making it ideal for students, -researchers or folks who simply want to see how it all works. - -A large collection of 3rd party ported software (the "ports -collection") is also provided to make it easier for you to obtain and -install all your favorite traditional UNIX utilities for FreeBSD. -Over 270 ports, comprising everything from the EMACS editor to the -lisp language, make FreeBSD a powerful and comprehensive operating -system that rivals that of many large workstations for general utility -and power. - - -For more documentation on this system, it is recommended that you -purchase the 4.4BSD Document Set from O'Reilly Associates and the -USENIX Association, ISBN 1-56592-082-1. We have no connection with -O'Reilly, we're just satisfied customers! - -You may also wish to read the HARDWARE GUIDE *before* proceeding any -further with the installation. Configuring PC hardware for anything -other than DOS/Windows (which don't actually make very significant -demands on the hardware) is actually quite a bit harder than it looks, -and if you think you understand PCs then you clearly haven't been -using them for long enough! :) This guide will give you some tips on -how to configure your hardware and what symptoms to watch for in case -of trouble. This guide is available in the Documentation menu of the -FreeBSD boot floppy. - -DISCLAIMER: While FreeBSD does its best to safeguard against accidental -loss of data, it's still more than possible to WIPE OUT YOUR ENTIRE DISK -with this installation! Please do not proceed to the final FreeBSD -installation menu unless you've adequately backed up any important -data first! We really mean it! - -Technical comments on this release should be sent to: - - hackers@FreeBSD.org - - -Bug reports should be sent using the `send-pr' command, if you were -able to get the system installed, otherwise to: - - bugs@FreeBSD.org - -Please be sure to indicate WHICH VERSION of FreeBSD you're running in -any bug reports! - - -General questions should be sent to: - - questions@FreeBSD.org - -Please have patience if your questions are not answered right away - -this is an especially busy time for us, and our volunteer resources -are often strained to the limit! Bug reports submitted with the -send-pr command are logged and tracked in our bugs database, and -you'll be kept informed of any changes in status during the life of -the bug (or feature request). - -Our WEB site, http://www.freebsd.org, is also a very good source for -updated information and provides a number of advanced documentation -facilities. You may use the BSDI version of Netscape for browsing the -World Wide Web directly from FreeBSD. - -You may also wish to look in /usr/share/FAQ and /usr/share/doc for -further information on the system. - - -Thanks for reading all of this, and we sincerely hope you enjoy this -release of FreeBSD! - - Jordan Hubbard, - for The FreeBSD Project diff --git a/share/FAQ/Text/REGISTER.FreeBSD b/share/FAQ/Text/REGISTER.FreeBSD deleted file mode 100644 index 85016289a404..000000000000 --- a/share/FAQ/Text/REGISTER.FreeBSD +++ /dev/null @@ -1,85 +0,0 @@ -In the absence of any other mechanism for counting the number of users -of FreeBSD, we like to kindly suggest that you take a few minutes to please -register with the counter set up by <Harald.T.Alvestrand@uninett.no>. - -The justification for such "registration" is twofold: First, we really would -like to know more about the size and demographics of our user-base in order -to better support its needs. Second, it's a sad fact of life that many -people rely on counters and statistics (even when highly dubious) rather -than on actual experience when chosing an operating system, and the best we -can hope to do in such circumstances is to at least try to provide some -indication of how popular we are (or are not). This is not how we recommend -that people go about chosing an operating system, but the necessity of -such "marketing" remains an undeniable fact. - -The FreeBSD team does not necessarily feel that Harald's counter represents -the best approach to such statistics gathering, and its accuracy can only -be as good as people's willingness to register with it (and may not reflect -the actual OS population at any single point in time), but in the total absence -of any other mechanism for providing such useful statistics, it's certainly a -start and we thank Harald for his efforts in providing this service. -It's a community service, and of potential benefit to everyone (all *BSD -users), so let's see if we can't make it work! - -Included below is the standard blurb from the counter. - -Thanks in advance, - - The FreeBSD team. - - -How to get registered -===================== - -In brief: - - [To register a running installation of FreeBSD] - Send E-mail to bsd-counter@uninett.no with the SUBJECT line - - "I use FreeBSD at <place>" - -Introduction -============ -The intention of this counting project is to count all users of UNIXes -that are: - - - BSD-derived - - Freely available - -The variants NetBSD, 386BSD and FreeBSD are currently distinguished. - -(NOTE: Linux is NOT BSD-derived. If you use that, send mail to -linux-counter@uninett.no instead!!!) - -The information is *not* used for any purpose but statistics, and unless -you request it, information about single persons are *never* made public. -(A list of users who have requested publication is available from the -FTP file ftp://aun.uninett.no/pub/misc/386bsd/persons) - -How to register -=============== -Send E-mail to bsd-counter@uninett.no - -The subject should be - - I use FreeBSD|NetBSD|386BSD at <place> - -Where FreeBSD, NetBSD or 386BSD is the particular variant you're using -and "place" can be school, work or home, or a combination of these. - -You will get back a letter with 3 things: - - - An acknowledgement - - A form that you can fill out and send in with more information - about yourself, your machine, and your 386bsd-using friends - - A report giving the current status of the counter - -You can update your "vote" at any time, by sending an E-mail message -from the same account. Duplicates will be weeded out. - -The current report, available by anonymous FTP to aun.uninett.no, -directory pub/misc/386bsd-counter, file "short", is given below. - -For all questions, contact Harald.T.Alvestrand@uninett.no! - -$Id: REGISTER.FreeBSD,v 1.2 1994/12/01 13:24:20 jkh Exp $ diff --git a/share/FAQ/Text/RELNOTES.FreeBSD b/share/FAQ/Text/RELNOTES.FreeBSD deleted file mode 100644 index 9b6c5c68e863..000000000000 --- a/share/FAQ/Text/RELNOTES.FreeBSD +++ /dev/null @@ -1,723 +0,0 @@ - RELEASE NOTES - FreeBSD - Release 2.0.5 - -1. Technical overview ---------------------- - -FreeBSD is a freely available, full source 4.4 BSD 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 some 8 months 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 4MB configuration a more acceptible -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've 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 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. Each -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. See the file: - /usr/share/FAQ/Text/ports.FAQ -for a more complete description of the ports collection. - - -Since our first release of FreeBSD 1.0 nearly two years ago, FreeBSD -has changed almost entirely. A new port from the Berkeley 4.4 code -base was done, which brought the legal status of the system out of the -shadows with the blessing of Novell (the new owners of USL and UNIX). The -port to 4.4 has also brought in a host of new features, filesystems -and enhanced driver support. With our new unencumbered code base, we -have every reason to hope that we'll be able to release quality -operating systems without further legal encumbrance for some time to -come! - -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! - -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. 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 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're outside (or even inside) -the U.S., give it a try! - - -1.1 What's new in 2.0.5? ----------------------- - -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. - -KERNEL: - -Merged VM-File Buffer Cache ---------------------------- -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) - - -Network PCB hash optimization ------------------------------ -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) - - -Name cache optimization ------------------------ -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) - - -Less restrictive swap-spaces ----------------------------- -The need to compile the names of the swap devices into the kernel has been -removed. Now swapon 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) - - -Hard Wired SCSI Devices ------------------------ -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 and prevent filesystems on -still functioning disks from mounting. 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 -scsi(4) man page or the LINT kernel config file. - -Owner: Peter Dufault (dufault@hda.com) -Sources involved: sys/scsi/* usr.sbin/config/* - - -Slice Support -------------- -FreeBSD now supports a "slice" abstraction which makes it more -completely interoperable with other operating system partitions. This -support will allow FreeBSD to inhabit DOS extended partitions. - -Owner: Bruce Evans (bde@FreeBSD.org) -Sources involved: sys/disklabel.h sys/diskslice.h sys/dkbad.h - kern/subr_diskslice.c kern/subr_dkbad.c - i386/isa/diskslice_machdep.c - i386/isa/wd.c scsi/sd.c dev/vn/vn.c - - -Support for Ontrack Disk Manager Version 6.0 --------------------------------------------- -Support has been added for disks which use Ontrack Disk Manager. The -fdisk program does NOT know about it however, so make all changes -using the install program on the boot.flp or the Ontrack Disk Manager -tool under DOS. - -Owner: Poul-Henning Kamp (phk@FreeBSD.org) - - -Bad144 is back and working --------------------------- -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) - - -NEW DEVICE SUPPORT: - - SCSI and CDROM Devices - -Matsushita/Panasonic (Creative) CD-ROM driver ---------------------------------------------- -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: isa/matcd - - -Adaptec 2742/2842/2940 SCSI driver ------------------------------ -The original 274x/284x driver has evolved considerably since the 2.0 -release. We now offer full support for the 2940 series as well as the -Wide models of these cards. The arbitration bug (as well as many -others) that caused the driver problems with fast devices has been -corrected and there is even experimental tagged queuing support -(kernel option "AHC_TAGENABLE"). 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: isa/aic7770.c pci/aic7870.c i386/scsi/* - sys/dev/aic7xxx/* - - -NCR5380/NCR53400 SCSI ("ProAudio Spectrum") driver --------------------------------------------------- -Owner: core -Submitted by: Serge Vakulenko (vak@cronyx.ru) -Sources involved: isa/ncr5380.c - - -Sony CDROM driver ------------------ -Owner: core -Submitted by: Mikael Hybsch (micke@dynas.se) -Sources involved: isa/scd.c - - - Serial Devices - -SDL Communications Riscom/8 Serial Board Driver ------------------------------------------------ -Owner: Andrey Chernov (ache@FreeBSD.org) -Sources involved: isa/rc.c isa/rcreg.h - - -Cyclades Cyclom-y Serial Board Driver -------------------------------------- -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: isa/cy.c - - -Cronyx/Sigma sync/async serial driver -------------------------------------- -Owner: core -Submitted by: Serge Vakulenko -Sources involved: isa/cronyx.c - - - - Networking - -Diskless booting ----------------- -Diskless booting in 2.0.5 is much improved. The boot-program is in -src/sys/i386/boot/netboot, and can be run from an MSDOS system or -burned into an EPROM. Local swapping is also possible. WD, SMC, 3COM -and Novell ethernet cards are currently supported. - - -DEC DC21140 Fast Ethernet driver --------------------------------- -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: pci/if_de.c pci/dc21040.h - - -DEC FDDI (DEFPA/DEFEA) driver ------------------------------ -Owner: core -Submitted by: Matt Thomas (thomas@lkg.dec.com) -Sources involved: pci/if_pdq.c pci/pdq.c pci/pdq_os.h pci/pdqreg.h - - -3Com 3c505 (Etherlink/+) NIC driver ------------------------------------ -Owner: core -Submitted by: Dean Huxley (dean@fsa.ca) -Obtained from: NetBSD -Sources involved: isa/if_eg.c - - -Fujitsu MB86960A family of NICs driver -------------------------------------- -Owner: core -Submitted by: M.S. (seki@sysrap.cs.fujitsu.co.jp) -Sources involved: isa/if_fe.c - - -Intel EtherExpress driver -------------------------- -Owner: Rodney W. Grimes (rgrimes@FreeBSD.org) -Sources involved: isa/if_ix.c isa/if_ixreg.h - - -3Com 3c589 driver ------------------ -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: isa/if_zp.c - - -IBM Credit Card Adapter driver ------------------------------- -Owner: core -Submitted by: "HOSOKAWA Tatsumi" (hosokawa@mt.cs.keio.ac.jp), -Sources involved: isa/pcic.c isa/pcic.h - - -EDSS1 and 1TR6 ISDN interface driver ------------------------------------- -Owner: core -Submitted by: Dietmar Friede (dfriede@drnhh.neuhaus.de) and - Juergen Krause (jkr@saarlink.de) -Sources involved: gnu/isdn/* - - - Miscellaneous Drivers - -Joystick driver ---------------- -Owner: Jean-Marc Zucconi (jmz@FreeBSD.org) -Sources involved: isa/joy.c - - -National Instruments "LabPC" driver ------------------------------------ -Owner: Peter Dufault (dufault@hda.com) -Sources involved: isa/labpc.c - - -WD7000 driver -------------- -Owner: Olof Johansson (offe@ludd.luth.se) - - -Pcvt Console driver -------------------- -Owner: Joerg Wunsch (joerg@FreeBSD.org) -Submitted by: Hellmuth Michaelis (hm@altona.hamburg.com) -Sources involved: isa/pcvt/* - - -BSD-audio emulator for VAT driver ---------------------------------- -Owner: Amancio Hasty (ahasty@FreeBSD.org) and - Paul Traina (pst@FreeBSD.org) -Sources involved: isa/sound/vat_audio.c isa/sound/vat_audioio.h - - -National Instruments AT-GPIB and AT-GPIB/TNT GPIB driver --------------------------------------------------------- -Owner: core -Submitted by: Fred Cawthorne (fcawth@delphi.umd.edu) -Sources involved: isa/gpib.c isa/gpib.h isa/gpibreg.h - - -Genius GS-4500 hand scanner driver ----------------------------------- -Owner: core -Submitted by: Gunther Schadow (gusw@fub46.zedat.fu-berlin.de) -Sources involved: isa/gsc.c isa/gscreg.h - - -CORTEX-I Frame Grabber ----------------------- -Owner: core -Submitted by: Paul S. LaFollette, Jr. ( -Sources involved: isa/ctx.c isa/ctxreg.h - - -Video Spigot video capture card -------------------------------- -Owner: Jim Lowe - - - -1.2 Experimental features ---------------------------------------------- - -The unionfs and LFS file systems are known to be severely broken in -2.0.5. This is in part due to old bugs that we haven't 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. - -FreeBSD now supports running iBCS2 compatible binaries (currently SCO -UNIX 3.2.2 & 3.2.4 and ISC 2.2 COFF format are supported). The iBCS2 -emulator is in its early stages, but it is functional, we haven't been -able to do exhaustive testing (lack of commercial apps), but almost -all of SCO's 3.2.2 binaries are working, so is an old INFORMIX-2.10 -for SCO. Further testing is nessesary to complete this project. There -is also work under way for ELF & XOUT loaders, and most of the svr4 -syscall wrappers have been written. - -Owner: Soren Schmidt (sos) & Sean Eric Fagan (sef) -Sources involved: sys/i386/ibcs2/* + misc kernel changes. -======= - - -2. Supported Configurations ---------------------------- - -FreeBSD currently runs on a wide variety of ISA, VLB, EISA and PCI bus -based PC's, ranging from 386sx to Pentium class machines (though the -386sx is not recommended). Support for generic IDE or ESDI drive -configurations, various SCSI controller, network and serial cards is -also provided. - -Following is a list of all disk controllers and ethernet cards currently -known to work with FreeBSD. Other configurations may very well work, and -we have simply not received any indication of this. - - -2.1. Disk Controllers - -WD1003 (any generic MFM/RLL) -WD1007 (any generic IDE/ESDI) -WD7000 -IDE -ATA - -Adaptec 152x series ISA SCSI controllers -Adaptec 154x series ISA SCSI controllers -Adaptec 174x series EISA SCSI controller in standard and enhanced mode. -Adaptec 274X/284X/2940 (Narrow/Wide/Twin) series ISA/EISA/PCI SCSI controllers -Adaptec AIC-6260 and AIC-6360 based boards, which includes -the AHA-152x and SoundBlaster SCSI cards. - -** Note: You cannot boot from the SoundBlaster cards -as they have no on-board BIOS, which is necessary for mapping -the boot device into the system BIOS I/O vectors. -They're perfectly usable for external tapes, CDROMs, etc, -however. The same goes for any other AIC-6x60 based card -without a boot ROM. Some systems DO have a boot ROM, which -is generally indicated by some sort of message when the system -is first powered up or reset. Check your system/board documentation -for more details. - -[Note that Buslogic was formerly known as "Bustec"] -Buslogic 545S & 545c -Buslogic 445S/445c VLB SCSI controller -Buslogic 742A, 747S, 747c EISA SCSI controller. -Buslogic 946c PCI SCSI controller -Buslogic 956c PCI SCSI controller - -NCR 53C810 and 53C825 PCI SCSI controller. -NCR5380/NCR53400 ("ProAudio Spectrum") SCSI controller. - -DTC 3290 EISA SCSI controller in 1542 emulation mode. - -UltraStor 14F, 24F and 34F SCSI controllers. - -Seagate ST01/02 SCSI controllers. - -Future Domain 8xx/950 series SCSI controllers. - -With all supported SCSI controllers, full support is provided for -SCSI-I & SCSI-II peripherals, including Disks, tape drives (including -DAT) and CD ROM drives. -The following CD-ROM type systems are supported at this time: -(cd) SCSI (also includes ProAudio Spectrum and SoundBlaster SCSI) -(mcd) Mitsumi proprietary interface -(matcd) Matsushita/Panasonic (Creative) proprietary interface -(scd) Sony proprietary interface - -Note: CD-Drives with IDE interfaces are not supported at this time. - -Some controllers have limitations with the way they deal with >16MB of -memory, due to the fact that the ISA bus only has a DMA address space -of 24 bits. If you do your arithmetic, you'll see that this makes it -impossible to do direct DMA to any address >16MB. This limitation is -even true of some EISA controllers (which are normally 32 bit) when -they're configured to emulate an ISA card, which they then do in *all* -respects. This problem is avoided entirely by IDE controllers (which -do not use DMA), true EISA controllers (like the UltraStor, Adaptec -1742A or Adaptec 2742) and most VLB (local bus) controllers. In the -cases where it's necessary, the system will use "bounce buffers" to -talk to the controller so that you can still use more than 16Mb of -memory without difficulty. - - -2.2. Ethernet cards - -SMC Elite 16 WD8013 ethernet interface, and most other WD8003E, -WD8003EBT, WD8003W, WD8013W, WD8003S, WD8003SBT and WD8013EBT -based clones. SMC Elite Ultra is also supported. - -DEC EtherWORKS III NICs (DE203, DE204, and DE205) -DEC EtherWORKS II NICs (DE200, DE201, DE202, and DE422) -DEC DC21140 based NICs (SMC???? DE???) -DEC FDDI (DEFPA/DEFEA) NICs - -Fujitsu MB86960A family of NICs - -Intel EtherExpress - -Isolan AT 4141-0 (16 bit) -Isolink 4110 (8 bit) - -Novell NE1000, NE2000, and NE2100 ethernet interface. - -3Com 3C501 cards - -3Com 3C503 Etherlink II - -3Com 3c505 Etherlink/+ - -3Com 3C507 Etherlink 16/TP - -3Com 3C509, 3C579, 3C589 (PCMCIA) Etherlink III - -Toshiba ethernet cards - -PCMCIA ethernet cards from IBM and National Semiconductor are also -supported. - - -2.3. Misc - -AST 4 port serial card using shared IRQ. - -ARNET 8 port serial card using shared IRQ. - -BOCA ATIO66 6 port serial card using shared IRQ. - -Cyclades Cyclom-y Serial Board. - -STB 4 port card using shared IRQ. - -Mitsumi (all models) CDROM interface and drive. - -SDL Communications Riscom/8 Serial Board. - -Soundblaster SCSI and ProAudio Spectrum SCSI CDROM interface and drive. - -Matsushita/Panasonic (Creative SoundBlaster) CDROM interface and drive. - -Adlib, SoundBlaster, SoundBlaster Pro, ProAudioSpectrum, Gravis UltraSound -and Roland MPU-401 sound cards. - -FreeBSD currently does NOT support IBM's microchannel (MCA) bus, but -support is apparently close to materializing. Details will be posted -as the situation develops. - - -3. Obtaining FreeBSD. ---------------------- - -You may obtain FreeBSD in a variety of ways: - -1. FTP/Mail - -You can ftp FreeBSD and any or all of its optional packages from -`ftp.freebsd.org' - the offical FreeBSD release site. - -For other locations that mirror the FreeBSD software see the file -MIRROR.SITES. Please ftp the distribution from the nearest site -to you netwise. - -If you do not have access to the internet and electronic mail is your -only recourse, then you may still fetch the files by sending mail to -`ftpmail@decwrl.dec.com' - putting the keyword "help" in your message -to get more information on how to fetch files from freebsd.cdrom.com. -Note: This approach will end up sending many *tens of megabytes* -through the mail, and should only be employed as an absolute LAST -resort! - - -2. CDROM - -FreeBSD 2.0.5 may be ordered on CDROM from: - - Walnut Creek CDROM - 4041 Pike Lane, Suite D - Concord CA 94520 - 1-800-786-9907, +1-510-674-0783, +1-510-674-0821 (fax) - -Or via the internet from orders@cdrom.com or http://www.cdrom.com. -Their current catalog can be obtained via ftp as: - ftp://ftp.cdrom.com/cdrom/catalog. - -Cost is $39.95. Shipping (per order not per disc) is $5 in the US, -Canada, or Mexico and $10.00 overseas. They accept Visa, Mastercard, -American Express, and ship COD within the United States. California -residents please add 8.25% sales tax. - -Should you be dissatisfied for any reason, the CD comes with an -unconditional return policy. - - -Reporting problems, making suggestions, submitting code. ------------------------------------------------------------ - -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 bugfiler program and you can -be sure that we'll 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: - - bugs@FreeBSD.org - - -Otherwise, for any questions or suggestions, please send mail to: - - questions@FreeBSD.org - -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: - - hackers@FreeBSD.org - -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: - - announce@FreeBSD.org - - -All but the freebsd-bugs groups can be freely joined by anyone wishing -to do so. Send mail to MajorDomo@FreeBSD.org 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! - - -6. Acknowledgements -------------------- - -FreeBSD represents the cumulative work of many dozens, if not -hundreds, of individuals from around the world who have worked very -hard to bring you this release. It would be very difficult, if not -impossible, to enumerate everyone who's contributed to FreeBSD, but -nonetheless we shall try (in alphabetical order, of course). If your -name is not mentioned, please be assured that its omission is entirely -accidental. - - -The Computer Systems Research Group (CSRG), U.C. Berkeley. - -Bill Jolitz, for his initial work with 386BSD. - -The FreeBSD Core Team -(in alphabetical order by first name): - - Andreas Schulz <ats@FreeBSD.org> - Andrey A. Chernov <ache@FreeBSD.org> - Bruce Evans <bde@FreeBSD.org> - David Greenman <davidg@FreeBSD.org> - Garrett A. Wollman <wollman@FreeBSD.org> - Gary Palmer <gpalmer@FreeBSD.org> - Geoff Rehmet <csgr@FreeBSD.org> - Jack Vogel <jackv@FreeBSD.org> - John Dyson <dyson@FreeBSD.org> - Jordan K. Hubbard <jkh@FreeBSD.org> - Justin Gibbs <gibbs@FreeBSD.org> - Paul Richards <paul@FreeBSD.org> - Poul-Henning Kamp <phk@FreeBSD.org> - Rich Murphey <rich@FreeBSD.org> - Rodney W. Grimes <rgrimes@FreeBSD.org> - Satoshi Asami <asami@FreeBSD.org> - Søren Schmidt <sos@FreeBSD.org> - -Special mention to: - - Walnut Creek CDROM, without whose help (and continuing support) - this release would never have been possible. - - Dermot McDonnell for his donation of a Toshiba XM3401B CDROM - drive. - - Additional FreeBSD helpers and beta testers: - - J.T. Conklin Julian Elischer - Frank Durda IV Peter Dufault - Sean Eric Fagan Jeffrey Hsu - Terry Lambert L Jonas Olsson - Chris Provenzano Dave Rivers - Guido van Rooij Steven Wallace - Atsushi Murai Scott Mace - Nate Williams - - And everyone at Montana State University for their initial support. - - -Jordan would also like to give special mention to Poul-Henning Kamp -and Gary Palmer, both of whom put in long hours helping him to -construct the new installation utility. Poul, being a proud new -father, was especially pressed for time yet somehow managed to put in -significant amount of effort anyway and this release could not have -happened without him. Thank you both! - -Thanks also to everyone else who helped, especially those not -mentioned, and we sincerely hope you enjoy this release of FreeBSD! - - - The FreeBSD Core Team - -$Id: RELNOTES.FreeBSD,v 1.6 1995/05/28 18:56:01 phk Exp $ diff --git a/share/FAQ/Text/ROADMAP b/share/FAQ/Text/ROADMAP deleted file mode 100644 index 956169114975..000000000000 --- a/share/FAQ/Text/ROADMAP +++ /dev/null @@ -1,58 +0,0 @@ -This directory contains frequently asked questions, short user guides, -tutorials and other miscellaneous information that may be of help -to the beginning (or even advanced) FreeBSD user. Any submissions -to this directory should be sent to: - - FreeBSD-FAQ@FreeBSD.ORG - -For inclusion with the next release. Your contributions are not only -welcome, but often save new users from uncountable headaches! If you've -written something you think may help new users, please - by all means -send it to us! - -Thanks! - - The FreeBSD Project - ----- -ROADMAP: - -File Description -=============================================================================== -ESDI.FAQ All about installing FreeBSD on older - ESDI/MFM drives. - -FreeBSD.FAQ The overall FreeBSD FAQ - posted regularly to - USENET. - -FreeBSD-1.1.FAQ FreeBSD FAQ for versions 1.1.5.1 and below. - -HW.TROUBLE User feedback on finicky or broken hardware. - -MIRROR.SITES A list of all sites mirroring FreeBSD 2.x. - -NFS.FAQ Tips for users using NFS between FreeBSD - and workstation hardware. - -Systems.FAQ Systems and configurations on which FreeBSD - is "known" to work. - -Systems-1.1.FAQ Systems for 1.1.5.1 and below - -current-policy.FAQ What you should know about running - FreeBSD-current. - -kernel-debug.FAQ How to debug kernels for 1.1.5.1 and below. - -mailing-list.FAQ All about the FreeBSD mailing lists. - -ports-supfile A sample supfile for the FreeBSD ports - collection. - -slip-dialup How to configure SLIP. - -standard-supfile A sample supfile for the FreeBSD source tree. - -sup.FAQ All about sup in general. - - diff --git a/share/FAQ/Text/TROUBLESHOOTING b/share/FAQ/Text/TROUBLESHOOTING deleted file mode 100644 index d1cb25fea992..000000000000 --- a/share/FAQ/Text/TROUBLESHOOTING +++ /dev/null @@ -1,185 +0,0 @@ -Troubleshooting Tips - or "These are the times that try men's souls" --------------------------------------------------------------------- - -The following tips and tricks may help you turn a failing (or failed) -installation attempt into a success. Please read them carefully. - ---- - -Symptom: Hardware conflict or misconfiguration. - Device not being found when it should be. - -Problem: A device is conflicting with another, or its settings - don't match the kernel's expected IRQ or address. - -Explanation: While most device drivers in FreeBSD are now smart - enough to match themselves to your hardware settings - dynamically, there are a few that still require fairly - rigid configuration parameters to be compiled in (and - matched by the hardware) before they'll work. We're - working hard to eliminate as many of these last - hold-outs as we can, but it's not always as easy as - it looks. - -Solution: There are several possible solutions. The first, - and easiest, is to boot the kernel with the -c flag. - When you see the initial boot prompt (from floppy or - hard disk), type: - - /kernel -c - - This will boot just past the memory sizing code and - then drop into a dynamic kernel configuration utility. - Type `?' at the prompt to see a list of commands. You - can use this utility to reset the IRQ, memory address, - IO address or a number of other device configuration - parameters. You can also disable a device entirely - if it's causing problems for other devices you'd much - rather have work. Note that this only affects the - kernel being booted temporarily, it does not "write out" - the information to the kernel so that these settings - are permanantly altered (this would be actually rather - hard). If you reboot, you'll have to make the same - changes again. The goal of the -c utility is to get - you up far enough to be able to download the appropriate - sources and configure and rebuild a kernel more specific - to your needs. - - Another solution is, obviously, to remove the offending - hardware or simply strip the system down to the bare - essentials until the problem (hopefully) goes away. - Once you're up, you can do the same thing mentioned - above - compile a kernel more suited to your hardware, - or incrementally try to figure out what it was about - your original hardware configuration that didn't work. - ---- -Symptom: My floppy-tape drive isn't probed. - -Problem: Last-minute problems with this driver caused it to be disabled - by default. - -Solution: Boot with -c (described above) and set the flags value of - fdc0 to 1. This will re-enable the floppy tape driver. - Sorry, but it was causing problems for people without floppy - tape drives! ---- - -Symptom: When I boot for the first time, it still looks for /386bsd! - -Problem: You still have the old FreeBSD 1.x boot blocks on your - boot partition. - -Solution: You should re-enter the installation process, invoke - the (F)disk editor and chose the (W)rite option. This - won't hurt an existing installation and will make sure - that the new boot blocks get written to the drive. - If you're installing for the first time, don't forget - to (W)rite out your new boot blocks! :-) - ---- - -Symptom: I want to boot FreeBSD off the second drive. It doesn't! - -Problem: FreeBSD will actually install just fine on a drive other - than 0 (the first drive), and the boot manager will even - allow you to select it, but the boot blocks rather - pathologically assume 0. This should be fixed in 2.1. - -Solution: Easy - follow these steps: - - 1. Select the first (0) drive from the (F)disk editor - and write out the boot manager with the (B) option. - This will enable the boot manager that allows you to - actually boot off the other drive. - - 2. Exit the fdisk editor for the first drive and and - re-enter it again for the drive you wish to install - on. Set up a partition on this drive, or select - (A)ll for the entire drive. - - 3. Enter the disklabel editor and allocate space on - your second drive as normal. Proceed with the - installation. - - 4. Once you've installed on the disk and are going to - reboot from the hard disk, enter the following at - the boot prompt: - - wd(1,a)/kernel - - [ If you're using a SCSI drive, substitute - `sd' for `wd' above ] - - This will ensure that you really boot from the second - drive. If you've actually installed on a drive other - than 1 (the 3rd or 4th drive?), substitute that number - in for the above. You will need to enter this EVERY - time you reboot from the hard disk. If you're feeling - brave and have a srcdist + the requisite experience, - you can hack the boot blocks in: - - /usr/src/sys/i386/boot/biosboot - - So that this drive you're booting from is hard-coded. - Recompile the boot blocks and reinstall them on your - drive with `disklabel -B ...' You can then have the - default Do The Right Thing. ---- - -Symptom: Newfs crashes, requesting that blocksize be 32K - -Problem: You have your disk controller configured to translate - to a some really large cylinder size because you're using - a drive with lots of cylinders. - -Solution: Turn such translation OFF in your controller's BIOS - setup if you can. If you must share the disk with other - Operating Systems, then this may not be possible and - you may simply be unable to install FreeBSD until we have - support for large translated geometries, sorry! - [ Hopefully in 2.1 ]. - ---- - -Symptom: FreeBSD won't boot off the hard disk - -Problem: Root partition does not start and end below cylinder 1024. - -Solution: See solution for newfs crashes, or move your root - partition. This limitation holds true for ANY operating - system you wish to boot from your hard drive. - ---- - -Symptom: FreeBSD still won't boot off the hard disk - -Problem: No boot code is installed in sector 1. - -Solution: Chose the Write MBR (B)oot code in the FDISK editor and - write out the boot manager so that you have a chance to - select operating systems. - - [ ** NOTE: If you are using the entire disk for FreeBSD, or - you have a Connor drive that does cylinder translation - from the MBR boot code, do NOT chose this option! ** ]. - ---- -Summary: Nope, FreeBSD's still not booting from the hard disk. - -Cause: BIOS disk geometry different from that used when - installing FreeBSD. - -Solution: With IDE drives, pay careful attention to the geometry - information that FreeBSD prints out when it's first - booting off the floppy. Use this geometry in your BIOS - setup or use the BIOS geometry when you install FreeBSD. - Either way, they have to match. - - With SCSI drives, the values they report is most often - bogus and cannot be used. In this situation, the SCSI - controller is performing geometry translation and - it's probably wise to assume a default of 64 heads, - 32 sectors and 1MB/cylinder. Use these values when - you install FreeBSD. See above comments concerning - newfs failures for more info. diff --git a/share/FAQ/Text/UUCP_Internals.FAQ b/share/FAQ/Text/UUCP_Internals.FAQ deleted file mode 100644 index 5a0702b5e0a0..000000000000 --- a/share/FAQ/Text/UUCP_Internals.FAQ +++ /dev/null @@ -1,1603 +0,0 @@ -Path: bloom-beacon.mit.edu!cambridge-news.cygnus.com!comton.airs.com!ian -From: ian@airs.com (Ian Lance Taylor) -Newsgroups: comp.mail.uucp,comp.answers,news.answers -Subject: UUCP Internals Frequently Asked Questions -Keywords: UUCP, protocol, FAQ -Message-ID: <uucp-internals_787915801@airs.com> -Date: 20 Dec 94 09:30:02 GMT -Expires: 31 Jan 95 09:30:01 GMT -Reply-To: ian@airs.com (Ian Lance Taylor) -Followup-To: comp.mail.uucp -Organization: Infinity Development, Waltham, MA -Lines: 1587 -Approved: news-answers-request@MIT.Edu -Supersedes: <uucp-internals_785496601@airs.com> -Xref: bloom-beacon.mit.edu comp.mail.uucp:5270 comp.answers:9043 news.answers:31575 - -Archive-name: uucp-internals -Version: $Revision: 1.1 $ -Last-modified: $Date: 1995/01/04 01:53:38 $ - - This article was written by Ian Lance Taylor <ian@airs.com> and I may - even update it periodically. Please send me mail about suggestions - or inaccuracies. - - This article describes how the various UUCP protocols work, and - discusses some other internal UUCP issues. It does not describe how - to configure UUCP, nor how to solve UUCP connection problems, nor how - to deal with UUCP mail. I do not know of any FAQ postings on these - topics. There are some documents on the net describing UUCP - configuration, but I can not keep an up to date list here; try using - archie. - - If you haven't read the news.announce.newusers articles, read them. - - This article is in digest format. Some newsreaders will be able to - break it apart into separate articles. Please don't ask me how to do - this, though. - - This article answers the following questions. If one of these - questions is posted to comp.mail.uucp, please send mail to the poster - referring her or him to this FAQ. There is no reason to post a - followup, as most of us know the answer already. - -Sources -What does "alarm" mean in debugging output? -What are UUCP grades? -What is the format of a UUCP lock file? -What is the format of a UUCP X.* file? -What is the UUCP protocol? -What is the 'g' protocol? -What is the 'f' protocol? -What is the 't' protocol? -What is the 'e' protocol? -What is the 'G' protocol? -What is the 'i' protocol? -What is the 'j' protocol? -What is the 'x' protocol? -What is the 'y' protocol? -What is the 'd' protocol? -What is the 'h' protocol? -What is the 'v' protocol? -Thanks - ----------------------------------------------------------------------- - -From: Sources -Subject: Sources - -"Unix-to-Unix Copy Program," said PDP-1. "You will never find a more -wretched hive of bugs and flamers. We must be cautious." - --DECWars - -I took a lot of the information from Jamie E. Hanrahan's paper in the -Fall 1990 DECUS Symposium, and from Managing UUCP and Usenet by Tim -O'Reilly and Grace Todino (with contributions by several other -people). The latter includes most of the former, and is published by - O'Reilly & Associates, Inc. - 103 Morris Street, Suite A - Sebastopol, CA 95472 -It is currently in its tenth edition. The ISBN number is -0-937175-93-5. - -Some information is originally due to a Usenet article by Chuck -Wegrzyn. The information on execution files comes partially from -Peter Honeyman. The information on the 'g' protocol comes partially -from a paper by G.L. Chesson of Bell Laboratories, partially from -Jamie E. Hanrahan's paper, and partially from source code by John -Gilmore. The information on the 'f' protocol comes from the source -code by Piet Berteema. The information on the 't' protocol comes from -the source code by Rick Adams. The information on the 'e' protocol -comes from a Usenet article by Matthias Urlichs. The information on -the 'd' protocol comes from Jonathan Clark, who also supplied -information about QFT. The FSUUCP information comes straight from -Christopher J. Ambler; it applies to version 1.4 and up. - -Although there are few books about UUCP, there are many about networks -and protocols in general. I recommend two non-technical books which -describe the sorts of things that are available on the network: ``The -Whole Internet,'' by Ed Krol, and ``Zen and the Art of the Internet,'' -by Brendan P. Kehoe. Good technical discussions of networking issues -can be found in ``Internetworking with TCP/IP,'' by Douglas E. Comer -and David L. Stevens and in ``Design and Validation of Computer -Protocols'' by Gerard J. Holzmann. - ------------------------------- - -From: alarm -Subject: What does "alarm" mean in debugging output? - -The debugging output of many versions of UUCP (but not Taylor UUCP) -will include messages like - alarm 1 -or - pkcget: alarm 1 - -This message means that the UUCP package has timed out while waiting -for some sort of response from the remote system. This normally -indicates some sort of connection problem. For example, the modems -might have lost their connection, or perhaps one of the modems will -not transmit the XON and XOFF characters, or perhaps one side or the -other is dropping characters. It can also mean that the packages -disagree about some aspect of the UUCP protocol, although this is less -common. - -Using the information in the rest of this posting, you should be able -to figure out what type of data your UUCP was expecting to receive. -This may give some indication as to exactly what the problem is. It -is difficult to be more specific, since there are many possiblities. - ------------------------------- - -From: UUCP-grades -Subject: What are UUCP grades? - -Modern UUCP packages support grades for each command. The grades -generally range from 'A' (the highest) to 'Z' followed by 'a' to 'z'. -Some UUCP packages also support '0' to '9' before 'A'. Some UUCP -packages may permit any ASCII character as a grade. - -On Unix, these grades are encoded in the name of the command file. A -command file name generally has the form - C.nnnngssss -where nnnn is the remote system name for which the command is queued, -g is a single character grade, and ssss is a four character sequence -number. For example, a command file created for the system ``airs'' -at grade 'Z' might be named - C.airsZ2551 - -The remote system name will be truncated to seven characters, to -ensure that the command file name will fit in the 14 character file -name limit of the traditional Unix file system. UUCP packages which -have no other means of distinguishing which command files are intended -for which systems thus require all systems they connect to to have -names that are unique in the first seven characters. Some UUCP -packages use a variant of this format which truncates the system name -to six characters. HDB and Taylor UUCP use a different spool -directory format, which allows up to fourteen characters to be used -for each system name. - -The sequence number in the command file name may be a decimal integer, -or it may be a hexadecimal integer, or it may contain any alphanumeric -character. Different UUCP packages are different. - -FSUUCP (a DOS based UUCP and news package) uses up to 8 characters for -file names in the spool (this is a DOS file name limitation; actually, -with the extension, 11 characters are available, but FSUUCP reserves -that for future use). FSUUCP defaults mail to grade D, and news to -grade N, except that when the grade of incoming mail can be -determined, that grade is preserved if the mail is forwarded to -another system. Mail and news are currently the only 2 types of -transfers supported. The default grades may be changed by editing -the MAIL.RC file for mail, or the FSUUCP.CFG file for news. - -UUPC/extended for DOS, OS/2 and Windows NT handles mail at grade 'C', -news at grade 'd', and file transfers at grade 'n'. The UUPC/extended -UUCP and RMAIL commands accept grades to override the default, the -others do not. - -I do not know how command grades are handled in other non-Unix UUCP -packages. - -Modern UUCP packages allow you to restrict file transfer by grade -depending on the time of day. Typically this is done with a line in -the Systems (or L.sys) file like this: - airs Any/Z,Any2305-0855 ... -This allows grades 'Z' and above to be transferred at any time. Lower -grades may only be transferred at night. I believe that this grade -restriction applies to local commands as well as to remote commands, -but I am not sure. It may only apply if the UUCP package places the -call, not if it is called by the remote system. - -Taylor UUCP can use the ``timegrade'' and ``call-timegrade'' commands -to achieve the same effect (and supports the above format when reading -Systems or L.sys). - -UUPC/extended provides the symmetricgrades option to announce the -current grade in effect when calling the remote system. - -This sort of grade restriction is most useful if you know what grades -are being used at the remote site. The default grades used depend on -the UUCP package. Generally uucp and uux have different defaults. A -particular grade can be specified with the -g option to uucp or uux. -For example, to request execution of rnews on airs with grade 'd', you -might use something like - uux -gd - airs!rnews <article - -Uunet queues up mail at grade 'C', but increases the grade based on -the size. News is queued at grade 'd', and file transfers at grade -'n'. The example above would allow mail (below some large size) to be -received at any time, but would only permit news to be transferred at -night. - ------------------------------- - -From: UUCP-lock-file -Subject: What is the format of a UUCP lock file? - -This discussion applies only to Unix. I have no idea how UUCP locks -ports on other systems. - -UUCP creates files to lock serial ports and systems. On most if not -all systems these same lock files are also used by cu to coordinate -access to serial ports. On some systems getty also uses these lock -files, often under the name uugetty. - -The lock file normally contains the process ID of the locking process. -This makes it easy to determine whether a lock is still valid. The -algorithm is to create a temporary file and then link it to the name -that must be locked. If the link fails because a file with that name -already exists, the existing file is read to get the process ID. If -the process still exists, the lock attempt fails. Otherwise the lock -file is deleted and the locking algorithm is retried. - -Older UUCP packages put the lock files in the main UUCP spool -directory, /usr/spool/uucp. HDB UUCP generally puts the lock files in -a directory of their own, usually /usr/spool/locks or /etc/locks. - -The original UUCP lock file format encodes the process ID as a four -byte binary number. The order of the bytes is host-dependent. HDB -UUCP stores the process ID as a ten byte ASCII decimal number, with a -trailing newline. For example, if process 1570 holds a lock file, it -would contain the eleven characters space, space, space, space, space, -space, one, five, seven, zero, newline. Some versions of UUCP add a -second line indicating which program created the lock (uucp, cu, or -getty/uugetty). I have also seen a third type of UUCP lock file which -does not contain the process ID at all. - -The name of the lock file is traditionally "LCK.." followed by the -base name of the device. For example, to lock /dev/ttyd0 the file -LCK..ttyd0 would be created. On SCO Unix, the lock file name is -always forced to lower case even if the device name has upper case -letters. - -System V Release 4 UUCP names the lock file using the major and minor -device numbers rather than the device name. The file is named -LK.XXX.YYY.ZZZ, where XXX, YYY and ZZZ are all three digit decimal -numbers. XXX is the major device number of the device holding the -directory holding the device file (e.g., /dev). YYY is the major -device number of the device file itself. ZZZ is the minor device -number of the device file itself. If s holds the result of passing -the device to the stat system call (e.g., stat ("/dev/ttyd0", &s)), -the following line of C code will print out the corresponding lock -file name: - printf ("LK.%03d.%03d.%03d", major (s.st_dev), - major (s.st_rdev), minor (s.st_rdev)); -The advantage of this system is that even if there are several links -to the same device, they will all use the same lock file name. - ------------------------------- - -From: X-file -Subject: What is the format of a UUCP X.* file? - -UUCP X.* files control program execution. They are created by uux. -They are transferred between computers just like any other file. The -uuxqt daemon reads them to figure out how to execute the job requested -by uux. - -An X.* file is simply a text file. The first character of each line -is a command, and the remainder of the line supplies arguments. The -following commands are defined: - C command - This gives the command to execute, including the program and - all arguments. For example, - C rmail ian@airs.com - U user system - This names the user who requested the command, and the system - from which the request came. - I standard-input - This names the file from which standard input is taken. If no - standard input file is given, the standard input will probably - be attached to /dev/null. If the standard input file is not - from the system on which the execution is to occur, it will - also appear in an F command. - O standard-output [ system ] - This names the standard output file. The optional second - argument names the system to which the file should be sent. - If there is no second argument, the file should be created on - the executing system. - F required-file [ filename-to-use ] - The F command can appear multiple times. Each F command names - a file which must exist before the execution can proceed. - This will usually be a file which is transferred from the - system on which uux was executed, but it can also be a file - from the local system or some other system. If the file is - not from the local system, then the command will usually name - a file in the spool directory. If the optional second - argument appears, then the file should be copied to the - execution directory under that name. This is necessary for - any file other than the standard input file. If the standard - input file is not from the local system, it will appear in - both an F command and an I command. - R requestor-address - This is the address to which mail about the job should be - sent. It is relative to the system named in the U command. - If the R command does not appear, then mail is sent to the - user named in the U command. - Z - This command takes no arguments. It means that a mail message - should be sent if the command failed. This is the default - behaviour for most modern UUCP packages, and for them the Z - command does not actually do anything. - N - This command takes no arguments. It means that no mail - message should be sent, even if the command failed. - n - This command takes no arguments. It means that a mail message - should be sent if the command succeeded. Normally a message - is sent only if the command failed. - B - This command takes no arguments. It means that the standard - input should be returned with any error message. This can be - useful in cases where the input would otherwise be lost. - e - This command takes no arguments. It means that the command - should be processed with /bin/sh. For some packages this is - the default anyhow. Most packages will refuse to execute - complex commands or commands containing wildcards, because of - the security holes this opens. - E - This command takes no arguments. It means that the command - should be processed with the execve system call. For some - packages this is the default anyhow. - M status-file - This command means that instead of mailing a message, the - message should be copied to the named file on the system named - by the U command. - # comment - This command is ignored, as is any other unrecognized command. - -Here is an example. Given the following command executed on system -test1 - uux - test2!cat - test2!~ian/bar !qux '>~/gorp' -(this is only an example, as most UUCP systems will not permit the cat -command to be executed) Taylor UUCP will produce the following X. -file: - U ian test1 - F D.test1N003r qux - O /usr/spool/uucppublic test1 - F D.test1N003s - I D.test1N003s - C cat - ~ian/bar qux -The standard input will be read into a file and then transferred to -the file D.test1N003s on system test2, and the file qux will be -transferred to D.test1N003r on system test2. When the command is -executed, the latter file will be copied to the execution directory -under the name qux. Note that since the file ~ian/bar is already on -the execution system, no action need be taken for it. The standard -output will be collected in a file, then copied to the directory -/usr/spool/uucppublic on the system test1. - ------------------------------- - -From: UUCP-protocol -Subject: What is the UUCP protocol? - -The UUCP protocol is a conversation between two UUCP packages. A UUCP -conversation consists of three parts: an initial handshake, a series -of file transfer requests, and a final handshake. - -Before the initial handshake, the caller will usually have logged in -the called machine and somehow started the UUCP package there. On -Unix this is normally done by setting the shell of the login name used -to /usr/lib/uucp/uucico. - -All messages in the initial handshake begin with a ^P (a byte with the -octal value \020) and end with a null byte (\000). A few systems end -these messages with a line feed character (\012) instead of a null -byte; the examples below assume a null byte is being used. - -Some options below are supported by QFT, which stands for Queued File -Transfer, and is (or was) an internal Bell Labs version of UUCP. - -Taylor UUCP size negotiation was introduced by Taylor UUCP, and is -also supported by DOS based FSUUCP and Amiga based wUUCP and -UUCP-1.17. - -The initial handshake goes as follows. It is begun by the called -machine. - -called: \020Shere=hostname\000 - The hostname is the UUCP name of the called machine. Older UUCP - packages do not output it, and simply send \020Shere\000. - -caller: \020Shostname options\000 - The hostname is the UUCP name of the calling machine. The - following options may appear (or there may be none): - -QSEQ - Report sequence number for this conversation. The - sequence number is stored at both sites, and incremented - after each call. If there is a sequence number mismatch, - something has gone wrong (somebody may have broken - security by pretending to be one of the machines) and the - call is denied. If the sequence number changes on one of - the machines, perhaps because of an attempted breakin or - because a disk backup was restored, the sequence numbers - on the two machines must be reconciled manually. This is - not supported by FSUUCP. - -xLEVEL - Requests the called system to set its debugging level to - the specified value. This is not supported by all - systems. - -pGRADE - -vgrade=GRADE - Requests the called system to only transfer files of the - specified grade or higher. This is not supported by all - systems. Some systems support -p, some support -vgrade=. - -R - Indicates that the calling UUCP understands how to restart - failed file transmissions. Supported only by System V - Release 4 UUCP and QFT. - -ULIMIT - Reports the ulimit value of the calling UUCP. The limit - is specified as a base 16 number in C notation (e.g., - -U0x1000000). This number is the number of 512 byte - blocks in the largest file which the calling UUCP can - create. The called UUCP may not transfer a file larger - than this. Supported only by System V Release 4 UUCP, QFT - and FSUUCP. FSUUCP reports the lesser of the - available disk space on the spool directory drive and the - ulimit variable in FSUUCP.CFG. - -N - Indicates that the calling UUCP understands the Taylor - UUCP size negotiation extension. Not supported by - traditional UUCP packages. - -called: \020ROK\000 - There are actually several possible responses. - ROK - The calling UUCP is acceptable, and the handshake proceeds - to the protocol negotiation. Some options may also - appear; see below. - ROKN - The calling UUCP is acceptable, it specified -N, and the - called UUCP also understands the Taylor UUCP size limiting - extensions. - RLCK - The called UUCP already has a lock for the calling UUCP, - which normally indicates the two machines are already - communicating. - RCB - The called UUCP will call back. This may be used to avoid - impostors (but only one machine out of each pair should - call back, or no conversation will ever begin). - RBADSEQ - The call sequence number is wrong (see the -Q discussion - above). - RLOGIN - The calling UUCP is using the wrong login name. - RYou are unknown to me - The calling UUCP is not known to the called UUCP, and the - called UUCP does not permit connections from unknown - systems. Some versions of UUCP just drop the line rather - than sending this message. - - If the response is ROK, the following options are supported by - System V Release 4 UUCP and QFT. - -R - The called UUCP knows how to restart failed file - transmissions. - -ULIMIT - Reports the ulimit value of the called UUCP. The limit is - specified as a base 16 number in C notation. This number - is the number of 512 byte blocks in the largest file which - the called UUCP can create. The calling UUCP may not send - a file larger than this. Also supported by FSUUCP. - -xLEVEL - I'm not sure just what this means. It may request the - calling UUCP to set its debugging level to the specified - value. - If the response is not ROK (or ROKN) both sides hang up the phone, - abandoning the call. - -called: \020Pprotocols\000 - Note that the called UUCP outputs two strings in a row. The - protocols string is a list of UUCP protocols supported by the - caller. Each UUCP protocol has a single character name. These - protocols are discussed in more detail later in this document. - For example, the called UUCP might send \020Pgf\000. - -caller: \020Uprotocol\000 - The calling UUCP selects which protocol to use out of the - protocols offered by the called UUCP. If there are no mutually - supported protocols, the calling UUCP sends \020UN\000 and both - sides hang up the phone. Otherwise the calling UUCP sends - something like \020Ug\000. - -Most UUCP packages will consider each locally supported protocol in -turn and select the first one supported by the called UUCP. With some -versions of HDB UUCP, this can be modified by giving a list of -protocols after the device name in the Devices file or the Systems -file. For example, to select the 'e' protocol in Systems, - airs Any ACU,e ... -or in Devices, - ACU,e ttyXX ... -Taylor UUCP provides the ``protocol'' command which may be used either -for a system or a port. - -After the protocol has been selected and the initial handshake has been -completed, both sides turn on the selected protocol. For some -protocols (notably 'g') a further handshake is done at this point. - -Each protocol supports a method for sending a command to the remote -system. This method is used to transmit a series of commands between -the two UUCP packages. At all times, one package is the master and -the other is the slave. Initially, the calling UUCP is the master. - -If a protocol error occurs during the exchange of commands, both sides -move immediately to the final handshake. - -The master will send one of four commands: S, R, X or H. - -Any file name referred to below is either an absolute pathname -beginning with "/", a public directory pathname beginning with "~/", a -pathname relative to a user's home directory beginning with "~USER/", -or a spool directory file name. File names in the spool directory are -not pathnames, but instead are converted to pathnames within the spool -directory by UUCP. They always begin with "C." (for a command file -created by uucp or uux), "D." (for a data file created by uucp, uux or -by an execution, or received from another system for an execution), or -"X." (for an execution file created by uux or received from another -system). - -master: S FROM TO USER -OPTIONS TEMP MODE NOTIFY SIZE - The S and the - are literal characters. This is a request by the - master to send a file to the slave. - FROM - The name of the file to send. If the C option does not - appear in OPTIONS, the master will actually open and send - this file. Otherwise the file has been copied to the - spool directory, where it is named TEMP. The slave - ignores this field unless TO is a directory, in which case - the basename of FROM will be used as the file name. If - FROM is a spool directory filename, it must be a data file - created for or by an execution, and must begin with "D.". - TO - The name to give the file on the slave. If this field - names a directory the file is placed within that directory - with the basename of FROM. A name ending in `/' is taken - to be a directory even if one does not already exist with - that name. If TO begins with `X.', an execution file will - be created on the slave. Otherwise, if TO begins with - `D.' it names a data file to be used by some execution - file. Otherwise, TO should not be in the spool directory. - USER - The name of the user who requested the transfer. - OPTIONS - A list of options to control the transfer. The following - options are defined (all options are single characters): - C - The file has been copied to the spool directory - (the master should use TEMP rather than FROM). - c - The file has not been copied to the spool - directory (this is the default). - d - The slave should create directories as necessary - (this is the default). - f - The slave should not create directories if - necessary, but should fail the transfer instead. - m - The master should send mail to USER when the - transfer is complete (not supported by FSUUCP). - n - The slave should send mail to NOTIFY when the - transfer is complete (not supported by FSUUCP). - TEMP - If the C option appears in OPTIONS, this names the file to - be sent. Otherwise if FROM is in the spool directory, - TEMP is the same as FROM. Otherwise TEMP may be a dummy - string, such as "D.0". After the transfer has been - succesfully completed, the master will delete the file - TEMP. - MODE - This is an octal number giving the mode of the file on - MASTER. If the file is not in the spool directory, the - slave will always create it with mode 0666, except that if - (MODE & 0111) is not zero (the file is executable), the - slave will create the file with mode 0777. If the file is - in the spool directory, some UUCP packages will use the - algorithm above and some will always create the file with - mode 0600. This field is not used by FSUUCP, since it is - meaningless on DOS. - NOTIFY - This field may not be present, and in any case is only - meaningful if the n option appears in OPTIONS. If the n - option appears, then when the transfer is successfully - completed, the slave will send mail to NOTIFY, which must - be a legal mailing address on the slave. If a SIZE field - will appear but the n option does not appear, NOTIFY will - always be present, typically as the string "dummy" or - simply a pair of double quotes. - SIZE - This field is only present when doing Taylor UUCP or SVR4 - UUCP size negotiation, It is the size of the file in - bytes. Taylor UUCP version 1.03 sends the size as a - decimal integer, while versions 1.04 and up, and all other - UUCP packages that support size negotiation, send the size - in base 16 with a leading 0x. - - The slave then responds with an S command response. - SY START - The slave is willing to accept the file, and file transfer - begins. The START field will only be present when using - file restart. It specifies the byte offset into the file - at which to start sending. If this is a new file, START - will be 0x0. - SN2 - The slave denies permission to transfer the file. This - can mean that the destination directory may not be - accessed, or that no requests are permitted. It implies - that the file transfer will never succeed. - SN4 - The slave is unable to create the necessary temporary - file. This implies that the file transfer might succeed - later. - SN6 - This is only used by Taylor UUCP size negotiation. It - means that the slave considers the file too large to - transfer at the moment, but it may be possible to transfer - it at some other time. - SN7 - This is only used by Taylor UUCP size negotiation. It - means that the slave considers the file too large to ever - transfer. - SN8 - This is only used by Taylor UUCP. It means that the file - was already received in a previous conversation. This can - happen if the receive acknowledgement was lost after it - was sent by the receiver but before it was received by the - sender. - SN9 - This is only used by Taylor UUCP (versions 1.05 and up) - and FSUUCP (versions 1.5 and up). It means that the - remote system was unable to open another channel (see the - discussion of the 'i' protocol for more information about - channels). This implies that the file transfer might - succeed later. - SN10 - This is reportedly used by SVR4 UUCP to mean that the file - size is too large. - - If the slave responds with SY, a file transfer begins. When the - file transfer is complete, the slave sends a C command response. - CY - The file transfer was successful. - CYM - The file transfer was successful, and the slave wishes to - become the master; the master should send an H command, - described below. - CN5 - The temporary file could not be moved into the final - location. This implies that the file transfer will never - succeed. - - After the C command response has been received (in the SY case) or - immediately (in an SN case) the master will send another command. - -master: R FROM TO USER -OPTIONS SIZE - The R and the - are literal characters. This is a request by the - master to receive a file from the slave. I do not know how SVR4 - UUCP or QFT implement file transfer restart in this case. - FROM - This is the name of the file on the slave which the master - wishes to receive. It must not be in the spool directory, - and it may not contain any wildcards. - TO - This is the name of the file to create on the master. I - do not believe that it can be a directory. It may only be - in the spool directory if this file is being requested to - support an execution either on the master or on some - system other than the slave. - USER - The name of the user who requested the transfer. - OPTIONS - A list of options to control the transfer. The following - options are defined (all options are single characters): - d - The master should create directories as necessary - (this is the default). - f - The master should not create directories if - necessary, but should fail the transfer instead. - m - The master should send mail to USER when the - transfer is complete. - SIZE - This only appears if Taylor UUCP size negotiation is being - used. It specifies the largest file which the master is - prepared to accept (when using SVR4 UUCP or QFT, this was - specified in the -U option during the initial handshake). - - The slave then responds with an R command response. FSUUCP does - not support R requests, and always responds with RN2. - RY MODE [ SIZE ] - The slave is willing to send the file, and file transfer - begins. MODE is the octal mode of the file on the slave. - The master treats this just as the slave does the MODE - argument in the send command, q.v. I am told that SVR4 - UUCP sends a trailing SIZE argument. For some versions of - BSD UUCP, the MODE argument may have a trailing M - character (e.g., RY 0666M). This means that the slave - wishes to become the master. - RN2 - The slave is not willing to send the file, either because - it is not permitted or because the file does not exist. - This implies that the file request will never succeed. - RN6 - This is only used by Taylor UUCP size negotiation. It - means that the file is too large to send, either because - of the size limit specifies by the master or because the - slave considers it too large. The file transfer might - succeed later, or it might not (this will be cleared up in - a later release of Taylor UUCP). - RN9 - This is only used by Taylor UUCP (versions 1.05 and up) - and FSUUCP (versions 1.5 and up). It means that the - remote system was unable to open another channel (see the - discussion of the 'i' protocol for more information about - channels). This implies that the file transfer might - succeed later. - - If the slave responds with RY, a file transfer begins. When the - file transfer is complete, the master sends a C command. The - slave pretty much ignores this, although it may log it. - CY - The file transfer was successful. - CN5 - The temporary file could not be moved into the final - location. - - After the C command response has been sent (in the RY case) or - immediately (in an RN case) the master will send another command. - -master: X FROM TO USER -OPTIONS - The X and the - are literal characters. This is a request by the - master to, in essence, execute uucp on the slave. The slave - should execute "uucp FROM TO". - FROM - This is the name of the file or files on the slave which - the master wishes to transfer. Any wildcards are expanded - on the slave. If the master is requesting that the files - be transferred to itself, the request would normally - contain wildcard characters, since otherwise an `R' - command would suffice. The master can also use this - command to request that the slave transfer files to a - third system. - TO - This is the name of the file or directory to which the - files should be transferred. This will normally use a - UUCP name. For example, if the master wishes to receive - the files itself, it would use "master!path". - USER - The name of the user who requested the transfer. - OPTIONS - A list of options to control the transfer. It is not - clear which, if any, options are supported by most UUCP - packages. - - The slave then responds with an X command response. FSUUCP does - not support X requests, and always responds with XN. - XY - The request was accepted, and the appropriate file - transfer commands have been queued up for later - processing. - XN - The request was denied. No particular reason is given. - - In either case, the master will then send another command. - -master: H - This is used by the master to hang up the connection. The slave - will respond with an H command response. - HY - The slave agrees to hang up the connection. In this case - the master sends another HY command. In some UUCP - packages the slave will then send a third HY command. At - this point the protocol is shut down, and the final - handshake is begun. - HN - The slave does not agree to hang up. In this case the - master and the slave exchange roles. The next command - will be sent by the former slave, which is the new master. - The roles may be reversed several times during a single - connection. - -After the protocol has been shut down, the final handshake is -performed. This handshake has no real purpose, and some UUCP packages -simply drop the connection rather than do it (in fact, some will drop -the connection immediately after both sides agree to hangup, without -even closing down the protocol). - -caller: \020OOOOOO\000 -called: \020OOOOOOO\000 - -That is, the calling UUCP sends six O's and the called UUCP replies -with seven O's. Some UUCP packages always send six O's. - ------------------------------- - -From: UUCP-g -Subject: What is the 'g' protocol? - -The 'g' protocol is a packet based flow controlled error correcting -protocol that requires an eight bit clear connection. It is the -original UUCP protocol, and is supported by all UUCP implementations. -Many implementations of it are only able to support small window and -packet sizes, specifically a window size of 3 and a packet size of 64 -bytes, but the protocol itself can support up to a window size of 7 -and a packet size of 4096 bytes. Complaints about the inefficiency of -the 'g' protocol generally refer to specific implementations, rather -than to the correctly implemented protocol. - -The 'g' protocol was originally designed for general packet drivers, -and thus contains some features that are not used by UUCP, including -an alternate data channel and the ability to renegotiate packet and -window sizes during the communication session. - -The 'g' protocol is spoofed by many Telebit modems. When spoofing is -in effect, each Telebit modem uses the 'g' protocol to communicate -with the attached computer, but the data between the modems is sent -using a Telebit proprietary error correcting protocol. This allows -for very high throughput over the Telebit connection, which, because -it is half-duplex, would not normally be able to handle the 'g' -protocol very well at all. When a Telebit is spoofing the 'g' -protocol, it forces the packet size to be 64 bytes and the window size -to be 3. - -This discussion of the 'g' protocol explains how it works, but does -not discuss useful error handling techniques. Some discussion of this -can be found in Jamie E. Hanrahan's paper, cited above. - -All 'g' protocol communication is done with packets. Each packet -begins with a six byte header. Control packets consist only of the -header. Data packets contain additional data. - -The header is as follows: - - \020 - Every packet begins with a ^P. - k (1 <= k <= 9) - The k value is always 9 for a control packet. For a data - packet, the k value indicates how much data follows the six - byte header. The amount of data is 2 ** (k + 4), where ** - indicates exponentiation. Thus a k value of 1 means 32 data - bytes and a k value of 8 means 4096 data bytes. The k value - for a data packet must be between 1 and 8 inclusive. - checksum low byte - checksum high byte - The checksum value is described below. - control byte - The control byte indicates the type of packet, and is - described below. - xor byte - This byte is the xor of k, the checksum low byte, the checksum - high byte and the control byte (i.e., the second, third, - fourth and fifth header bytes). It is used to ensure that the - header data is valid. - -The control byte in the header is composed of three bit fields, -referred to here as TT (two bits), XXX (three bits) and YYY (three -bits). The control is TTXXXYYY, or (TT << 6) + (XXX << 3) + YYY. - -The TT field takes on the following values: - 0 - This is a control packet. In this case the k byte in the - header must be 9. The XXX field indicates the type of control - packet; these types are described below. - 1 - This is an alternate data channel packet. This is not used by - UUCP. - 2 - This is a data packet, and the entire contents of the attached - data field (whose length is given by the k byte in the header) - are valid. The XXX and YYY fields are described below. - 3 - This is a short data packet. Let the length of the data field - (as given by the k byte in the header) be L. Let the first - byte in the data field be B1. If B1 is less than 128 (if the - most significant bit of B1 is 0), then there are L - B1 valid - bytes of data in the data field, beginning with the second - byte. If B1 >= 128, let B2 be the second byte in the data - field. Then there are L - ((B1 & 0x7f) + (B2 << 7)) valid - bytes of data in the data field, beginning with the third - byte. In all cases L bytes of data are sent (and all data - bytes participate in the checksum calculation) but some of the - trailing bytes may be dropped by the receiver. The XXX and - YYY fields are described below. - -In a data packet (short or not) the XXX field gives the sequence -number of the packet. Thus sequence numbers can range from 0 to 7, -inclusive. The YYY field gives the sequence number of the last -correctly received packet. - -Each communication direction uses a window which indicates how many -unacknowledged packets may be transmitted before waiting for an -acknowledgement. The window may range from 1 to 7, and may be -different in each direction. For example, if the window is 3 and the -last packet acknowledged was packet number 6, packet numbers 7, 0 and -1 may be sent but the sender must wait for an acknowledgement before -sending packet number 2. This acknowledgement could come as the YYY -field of a data packet or as the YYY field of a RJ or RR control -packet (described below). - -Each packet must be transmitted in order (the sender may not skip -sequence numbers). Each packet must be acknowledged, and each packet -must be acknowledged in order. - -In a control packet, the XXX field takes on the following values: - 1 CLOSE - The connection should be closed immediately. This is - typically sent when one side has seen too many errors and - wants to give up. It is also sent when shutting down the - protocol. If an unexpected CLOSE packet is received, a CLOSE - packet should be sent in reply and the 'g' protocol should - halt, causing UUCP to enter the final handshake. - 2 RJ or NAK - The last packet was not received correctly. The YYY field - contains the sequence number of the last correctly received - packet. - 3 SRJ - Selective reject. The YYY field contains the sequence number - of a packet that was not received correctly, and should be - retransmitted. This is not used by UUCP, and most - implementations will not recognize it. - 4 RR or ACK - Packet acknowledgement. The YYY field contains the sequence - number of the last correctly received packet. - 5 INITC - Third initialization packet. The YYY field contains the - maximum window size to use. - 6 INITB - Second initialization packet. The YYY field contains the - packet size to use. It requests a size of 2 ** (YYY + 5). - Note that this is not the same coding used for the k byte in - the packet header (it is 1 less). Most UUCP implementations - that request a packet size larger than 64 bytes can handle any - packet size up to that specified. - 7 INITA - First initialization packet. The YYY field contains the - maximum window size to use. - -The checksum of a control packet is simply 0xaaaa - the control byte. - -The checksum of a data packet is 0xaaaa - (CHECK ^ the control byte), -where ^ denotes exclusive or, and CHECK is the result of the following -routine as run on the contents of the data field (every byte in the -data field participates in the checksum, even for a short data -packet). Below is the routine used by Taylor UUCP; it is a slightly -modified version of a routine which John Gilmore patched from G.L. -Chesson's original paper. The z argument points to the data and the c -argument indicates how much data there is. - -int -igchecksum (z, c) - register const char *z; - register int c; -{ - register unsigned int ichk1, ichk2; - - ichk1 = 0xffff; - ichk2 = 0; - - do - { - register unsigned int b; - - /* Rotate ichk1 left. */ - if ((ichk1 & 0x8000) == 0) - ichk1 <<= 1; - else - { - ichk1 <<= 1; - ++ichk1; - } - - /* Add the next character to ichk1. */ - b = *z++ & 0xff; - ichk1 += b; - - /* Add ichk1 xor the character position in the buffer counting from - the back to ichk2. */ - ichk2 += ichk1 ^ c; - - /* If the character was zero, or adding it to ichk1 caused an - overflow, xor ichk2 to ichk1. */ - if (b == 0 || (ichk1 & 0xffff) < b) - ichk1 ^= ichk2; - } - while (--c > 0); - - return ichk1 & 0xffff; -} - -When the 'g' protocol is started, the calling UUCP sends an INITA -control packet with the window size it wishes the called UUCP to use. -The called UUCP responds with an INITA packet with the window size it -wishes the calling UUCP to use. Pairs of INITB and INITC packets are -then similarly exchanged. When these exchanges are completed, the -protocol is considered to have been started. - -Note that the window and packet sizes are not a negotiation. Each -system announces the window and packet size which the other system -should use. It is possible that different window and packet sizes -will be used in each direction. The protocol works this way on the -theory that each system knows how much data it can accept without -getting overrun. Therefore, each system tells the other how much data -to send before waiting for an acknowledgement. - -When a UUCP package transmits a command, it sends one or more data -packets. All the data packets will normally be complete, although -some UUCP packages may send the last one as a short packet. The -command string is sent with a trailing null byte, to let the receiving -package know when the command is finished. Some UUCP packages require -the last byte of the last packet sent to be null, even if the command -ends earlier in the packet. Some packages may require all the -trailing bytes in the last packet to be null, but I have not confirmed -this. - -When a UUCP package sends a file, it will send a sequence of data -packets. The end of the file is signalled by a short data packet -containing zero valid bytes (it will normally be preceeded by a short -data packet containing the last few bytes in the file). - -Note that the sequence numbers cover the entire communication session, -including both command and file data. - -When the protocol is shut down, each UUCP package sends a CLOSE -control packet. - ------------------------------- - -From: UUCP-f -Subject: What is the 'f' protocol? - -The 'f' protocol is a seven bit protocol which checksums an entire -file at a time. It only uses the characters between \040 and \176 -(ASCII space and ~) inclusive as well as the carriage return -character. It can be very efficient for transferring text only data, -but it is very inefficient at transferring eight bit data (such as -compressed news). It is not flow controlled, and the checksum is -fairly insecure over large files, so using it over a serial connection -requires handshaking (XON/XOFF can be used) and error correcting -modems. Some people think it should not be used even under those -circumstances. - -I believe the 'f' protocol originated in BSD versions of UUCP. It was -originally intended for transmission over X.25 PAD links. - -The 'f' protocol has no startup or finish protocol. However, both -sides typically sleep for a couple of seconds before starting up, -because they switch the terminal into XON/XOFF mode and want to allow -the changes to settle before beginning transmission. - -When a UUCP package transmits a command, it simply sends a string -terminated by a carriage return. - -When a UUCP package transmits a file, each byte b of the file is -translated according to the following table: - - 0 <= b <= 037: 0172, b + 0100 (0100 to 0137) - 040 <= b <= 0171: b ( 040 to 0171) - 0172 <= b <= 0177: 0173, b - 0100 ( 072 to 077) - 0200 <= b <= 0237: 0174, b - 0100 (0100 to 0137) - 0240 <= b <= 0371: 0175, b - 0200 ( 040 to 0171) - 0372 <= b <= 0377: 0176, b - 0300 ( 072 to 077) - -That is, a byte between \040 and \171 inclusive is transmitted as is, -and all other bytes are prefixed and modified as shown. - -When all the file data is sent, a seven byte sequence is sent: two -bytes of \176 followed by four ASCII bytes of the checksum as printed -in base 16 followed by a carriage return. For example, if the -checksum was 0x1234, this would be sent: "\176\1761234\r". - -The checksum is initialized to 0xffff. For each byte that is sent it -is modified as follows (where b is the byte before it has been -transformed as described above): - - /* Rotate the checksum left. */ - if ((ichk & 0x8000) == 0) - ichk <<= 1; - else - { - ichk <<= 1; - ++ichk; - } - - /* Add the next byte into the checksum. */ - ichk += b; - -When the receiving UUCP sees the checksum, it compares it against its -own calculated checksum and replies with a single character followed -by a carriage return. - G - The file was received correctly. - R - The checksum did not match, and the file should be resent from - the beginning. - Q - The checksum did not match, but too many retries have occurred - and the communication session should be abandoned. - -The sending UUCP checks the returned character and acts accordingly. - ------------------------------- - -From: UUCP-t -Subject: What is the 't' protocol? - -The 't' protocol is intended for use on links which provide reliable -end-to-end connections, such as TCP. It does no error checking or -flow control, and requires an eight bit clear channel. - -I believe the 't' protocol originated in BSD versions of UUCP. - -When a UUCP package transmits a command, it first gets the length of -the command string, C. It then sends ((C / 512) + 1) * 512 bytes (the -smallest multiple of 512 which can hold C bytes plus a null byte) -consisting of the command string itself followed by trailing null -bytes. - -When a UUCP package sends a file, it sends it in blocks. Each block -contains at most 1024 bytes of data. Each block consists of four -bytes containing the amount of data in binary (most significant byte -first, the same format as used by the Unix function htonl) followed by -that amount of data. The end of the file is signalled by a block -containing zero bytes of data. - ------------------------------- - -From: UUCP-e -Subject: What is the 'e' protocol? - -The 'e' protocol is similar to the 't' protocol. It does no flow -control or error checking and is intended for use over networks -providing reliable end-to-end connections, such as TCP. - -The 'e' protocol originated in versions of HDB UUCP. - -When a UUCP package transmits a command, it simply sends the command -as an ASCII string terminated by a null byte. - -When a UUCP package transmits a file, it sends the complete size of -the file as an ASCII decimal number. The ASCII string is padded out -to 20 bytes with null bytes (i.e. if the file is 1000 bytes long, it -sends "1000\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"). It then sends the -entire file. - ------------------------------- - -From: UUCP-G -Subject: What is the 'G' protocol? - -The 'G' protocol is used by SVR4 UUCP. It is identical to the 'g' -protocol, except that it is possible to modify the window and packet -sizes. The SVR4 implementation of the 'g' protocol reportedly is -fixed at a packet size of 64 and a window size of 7. Supposedly SVR4 -chose to implement a new protocol using a new letter to avoid any -potential incompatibilities when using different packet or window -sizes. - -Most implementations of the 'g' protocol that accept packets larger -than 64 bytes will also accept packets smaller than whatever they -requested in the INITB packet. The SVR4 'G' implementation is an -exception; it will only accept packets of precisely the size it -requests in the INITB packet. - ------------------------------- - -From: UUCP-i -Subject: What is the 'i' protocol? - -The 'i' protocol was written by Ian Lance Taylor (who also wrote this -FAQ). It is used by Taylor UUCP version 1.04. - -It is a sliding window packet protocol, like the 'g' protocol, but it -supports bidirectional transfers (i.e., file transfers in both -directions simultaneously). It requires an eight bit clear -connection. Several ideas for the protocol were taken from the paper -``A High-Throughput Message Transport System'' by P. Lauder. I don't -know where the paper was published, but the author's e-mail address is -piers@cs.su.oz.au. The 'i' protocol does not adopt his main idea, -which is to dispense with windows entirely. This is because some -links still do require flow control and, more importantly, because -using windows sets a limit to the amount of data which the protocol -must be able to resend upon request. To reduce the costs of window -acknowledgements, the protocol uses a large window and only requires -an ack at the halfway point. - -Each packet starts with a six byte header, optionally followed by data -bytes with a four byte checksum. There are currently five defined -packet types (DATA, SYNC, ACK, NAK, SPOS, CLOSE) which are described -below. Although any packet type may include data, any data provided -with an ACK, NAK or CLOSE packet is ignored. - -Every DATA, SPOS and CLOSE packet has a sequence number. The sequence -numbers are independent for each side. The first packet sent by each -side is always number 1. Each packet is numbered one greater than the -previous packet, modulo 32. - -Every packet has a local channel number and a remote channel number. -For all packets at least one channel number is zero. When a UUCP -command is sent to the remote system, it is assigned a non-zero local -channel number. All packets associated with that UUCP command sent by -the local system are given the selected local channel number. All -associated packets sent by the remote system are given the selected -number as the remote channel number. This permits each UUCP command -to be uniquely identified by the channel number on the originating -system, and therefore each UUCP package can associate all file data -and UUCP command responses with the appropriate command. This is a -requirement for bidirectional UUCP transfers. - -The protocol maintains a single global file position, which starts at -0. For each incoming packet, any associated data is considered to -occur at the current file position, and the file position is -incremented by the amount of data contained. The exception is a -packet of type SPOS, which is used to change the file position. -The reason for keeping track of the file position is described below. - -The header is as follows: - - \007 - Every packet begins with ^G. - (PACKET << 3) + LOCCHAN - The five bit packet number combined with the three bit local - channel number. DATA, SPOS and CLOSE packets use the packet - sequence number for the PACKET field. NAK packet types use - the PACKET field for the sequence number to be resent. ACK - and SYNC do not use the PACKET field, and generally leave it - set to 0. Packets which are not associated with a UUCP - command from the local system use a local channel number of 0. - (ACK << 3) + REMCHAN - The five bit packet acknowledgement combined with the three - bit remote channel number. The packet acknowledgement is the - number of the last packet successfully received; it is used by - all packet types. Packets which are not sent in response to a - UUCP command from the remote system use a remote channel - number of 0. - (TYPE << 5) + (CALLER << 4) + LEN1 - The three bit packet type combined with the one bit packet - direction combined with the upper four bits of the data - length. The packet direction bit is always 1 for packets sent - by the calling UUCP, and 0 for packets sent by the called - UUCP. This prevents confusion caused by echoed packets. - LEN2 - The lower eight bits of the data length. The twelve bits of - data length permit packets ranging in size from 0 to 4095 - bytes. - CHECK - The exclusive or of the second through fifth bytes of the - header. This provides an additional check that the header is - valid. - -If the data length is non-zero, the packet is immediately followed by -the specified number of data bytes. The data bytes are followed by a -four byte CRC 32 checksum, with the most significant byte first. The -CRC is calculated over the contents of the data field. - -The defined packet types are as follows: - - 0 (DATA) - This is a plain data packet. - 1 (SYNC) - SYNC packets are exchanged when the protocol is initialized, - and are described further below. SYNC packets do not carry - sequence numbers (that is, the PACKET field is ignored). - 2 (ACK) - This is an acknowledgement packet. Since DATA packets also - carry packet acknowledgements, ACK packets are only used when - one side has no data to send. ACK packets do not carry - sequence numbers. - 3 (NAK) - This is a negative acknowledgement. This is sent when a - packet is received incorrectly, and means that the packet - number appearing in the PACKET field must be resent. NAK - packets do not carry sequence numbers (the PACKET field is - already used). - 4 (SPOS) - This packet changes the file position. The packet contains - four bytes of data holding the file position, most significant - byte first. The next packet received will be considered to be - at the named file position. - 5 (CLOSE) - When the protocol is shut down, each side sends a CLOSE - packet. This packet does have a sequence number, which could - be used to ensure that all packets were correctly received - (this is not needed by UUCP, however, which uses the higher - level H command with an HY response). - -When the protocol starts up, both systems send a SYNC packet. The -SYNC packet includes at least three bytes of data. The first two -bytes are the maximum packet size the remote system should send, most -significant byte first. The third byte is the window size the remote -system should use. The remote system may send packets of any size up -to the maximum. If there is a fourth byte, it is the number of -channels the remote system may use (this must be between 1 and 7, -inclusive). Additional data bytes may be defined in the future. - -The window size is the number of packets that may be sent before a -packet is acknowledged. There is no requirement that every packet be -acknowledged; any acknowledgement is considered to acknowledge all -packets through the number given. In the current implementation, if -one side has no data to send, it sends an ACK when half the window is -received. - -Note that the NAK packet corresponds to the unused 'g' protocol SRJ -packet type, rather than to the RJ packet type. When a NAK is -received, only the named packet should be resent, not any subsequent -packets. - -Note that if both sides have data to send, but a packet is lost, it is -perfectly reasonable for one side to continue sending packets, all of -which will acknowledge the last packet correctly received, while the -system whose packet was lost will be unable to send a new packet -because the send window will be full. In this circumstance, neither -side will time out and one side of the communication will be -effectively shut down for a while. Therefore, any system with -outstanding unacknowledged packets should arrange to time out and -resend a packet even if data is being received. - -Commands are sent as a sequence of data packets with a non-zero local -channel number. The last data packet for a command includes a -trailing null byte (normally a command will fit in a single data -packet). Files are sent as a sequence of data packets ending with one -of length zero. - -The channel numbers permit a more efficient implementation of the UUCP -file send command. Rather than send the command and then wait for the -SY response before sending the file, the file data is sent beginning -immediately after the S command is sent. If an SN response is -received, the file send is aborted, and a final data packet of length -zero is sent to indicate that the channel number may be reused. If an -SY reponse with a file position indicator is received, the file send -adjusts to the file position; this is why the protocol maintains a -global file position. - -Note that the use of channel numbers means that each UUCP system may -send commands and file data simultaneously. Moreover, each UUCP -system may send multiple files at the same time, using the channel -number to disambiguate the data. Sending a file before receiving an -acknowledgement for the previous file helps to eliminate the round -trip delays inherent in other UUCP protocols. - ------------------------------- - -From: UUCP-j -Subject: What is the 'j' protocol? - -The 'j' protocol is a variant of the 'i' protocol. It was also -written by Ian Lance Taylor, and first appeared in Taylor UUCP version -1.04. - -The 'j' protocol is a version of the 'i' protocol designed for -communication links which intercept a few characters, such as XON or -XOFF. It is not efficient to use it on a link which intercepts many -characters, such as a seven bit link. The 'j' protocol performs no -error correction or detection; that is presumed to be the -responsibility of the 'i' protocol. - -When the 'j' protocol starts up, each system sends a printable ASCII -string indicating which characters it wants to avoid using. The -string begins with the ASCII character '^' (octal 136) and ends with -the ASCII character '~' (octal 176). After sending this string, each -system looks for the corresponding string from the remote system. The -strings are composed of escape sequences: \ooo, where o is an octal -digit. For example, sending the string ^\021\023~ means that the -ASCII XON and XOFF characters should be avoided. The union of the -characters described in both strings (the string which is sent and the -string which is received) is the set of characters which must be -avoided in this conversation. Avoiding a printable ASCII character -(octal 040 to octal 176, inclusive) is not permitted. - -After the exchange of characters to avoid, the normal 'i' protocol -start up is done, and the rest of the conversation uses the normal 'i' -protocol. However, each 'i' protocol packet is wrapped to become a -'j' protocol packet. - -Each 'j' protocol packet consists of a seven byte header, followed by -data bytes, followed by index bytes, followed by a one byte trailer. -The packet header looks like this: - - ^ - Every packet begins with the ASCII character '^', octal 136. - HIGH - LOW - These two characters give the total number of bytes in the - packet. Both HIGH and LOW are printable ASCII characters. - The length of the packet is (HIGH - 040) * 0100 + (LOW - 040), - where 040 <= HIGH < 0177 and 040 <= LOW < 0140. This permits - a length of 6079 bytes, but there is a further restriction on - packet size described below. - = - The ASCII character '=', octal 075. - DATA-HIGH - DATA-LOW - These two characters give the total number of data bytes in - the packet. The encoding is as described for HIGH and LOW. - The number of data bytes is the size of the 'i' protocol - packet wrapped inside this 'j' protocol packet. - @ - The ASCII character '@', octal 100. - -The header is followed by the number of data bytes given in DATA-HIGH -and DATA-LOW. These data bytes are the 'i' protocol packet which is -being wrapped in the 'j' protocol packet. However, each character in -the 'i' protocol packet which the 'j' protocol must avoid is -transformed into a printable ASCII character (recall that avoiding a -printable ASCII character is not permitted). Two index bytes are used -for each character which must be transformed. - -The index bytes immediately follow the data bytes. The index bytes -are created in pairs. Each pair of index bytes encodes the location -of a character in the 'i' protocol packet which was transformed to -become a printable ASCII character. Each pair of index bytes also -encodes the precise transformation which was performed. - -When the sender finds a character which must be avoided, it will -transform it using one or two operations. If the character is 0200 or -greater, it will subtract 0200. If the resulting character is less -than 020, or is equal to 0177, it will xor by 020. The result is -a printable ASCII character. - -The zero based byte index of the character within the 'i' protocol -packet is determined. This index is turned into a two byte printable -ASCII index, INDEX-HIGH and INDEX-LOW, such that the index is -(INDEX-HIGH - 040) * 040 + (INDEX-LOW - 040). INDEX-LOW is restricted -such that 040 <= INDEX-LOW < 0100. INDEX-HIGH is not permitted to be -0176, so 040 <= INDEX-HIGH < 0176. INDEX-LOW is then modified to -encode the transformation: - - If the character transformation only had to subtract 0200, then - INDEX-LOW is used as is. - - If the character transformation only had to xor by 020, then 040 - is added to INDEX-LOW. - - If both operations had to be performed, then 0100 is added to - INDEX-LOW. However, if the value of INDEX-LOW were initially 077, - then adding 0100 would result in 0177, which is not a printable - ASCII character. For that special case, INDEX-HIGH is set to - 0176, and INDEX-LOW is set to the original value of INDEX-HIGH. - -The receiver decodes the index bytes as follows (this is the reverse -of the operations performed by the sender, presented here for -additional clarity): - - The first byte in the index is INDEX-HIGH, and the second is - INDEX-LOW. - - If 040 <= INDEX-HIGH < 0176, the index refers to the data byte at - position (INDEX-HIGH - 040) * 040 + INDEX-LOW % 040. - - If 040 <= INDEX-LOW < 0100, then 0200 must be added to indexed - byte. - - If 0100 <= INDEX-LOW < 0140, then 020 must be xor'ed to the - indexed byte. - - If 0140 <= INDEX-LOW < 0177, then 0200 must be added to the - indexed byte, and 020 must be xor'ed to the indexed byte. - - If INDEX-HIGH == 0176, the index refers to the data byte at - position (INDEX-LOW - 040) * 040 + 037. 0200 must be added to the - indexed byte, and 020 must be xor'ed to the indexed byte. - -This means the largest 'i' protocol packet which may be wrapped inside -a 'j' protocol packet is (0175 - 040) * 040 + (077 - 040) == 3007 -bytes. - -The final character in a 'j' protocol packet, following the index -bytes, is the ASCII character '~' (octal 176). - -The motivation behind using an indexing scheme, rather than escape -characters, is to avoid data movement. The sender may simply add a -header and a trailer to the 'i' protocol packet. Once the receiver -has loaded the 'j' protocol packet, it may scan the index bytes, -transforming the data bytes, and then pass the data bytes directly on -to the 'i' protocol routine. - ------------------------------- - -From: UUCP-x -Subject: What is the 'x' protocol? - -The 'x' protocol is used in Europe (and probably elsewhere) with -machines that contain an builtin X.25 card and can send eight bit data -transparently across X.25 circuits, without interference from the X.28 -or X.29 layers. The protocol sends packets of 512 bytes, and relies -on a write of zero bytes being read as zero bytes without stopping -communication. It first appeared in the original System V UUCP -implementation. - ------------------------------- - -From: UUCP-y -Subject: What is the 'y' protocol? - -The 'y' protocol was developed by Jorge Cwik for use in FX UUCICO, a -PC uucico program. It is designed for communication lines which -handle error correction and flow control. It is a streaming protocol, -like the 'f' protocol. It requires an eight bit clean connection. It -performs error detection, but not error correction; when an error is -detected, the line is dropped. I do not know the implementation -details. - ------------------------------- - -From: UUCP-d -Subject: What is the 'd' protocol? - -This is apparently used for DataKit muxhost (not RS-232) connections. -No file size is sent. When a file has been completely transferred, a -write of zero bytes is done; this must be read as zero bytes on the -other end. - ------------------------------- - -From: UUCP-h -Subject: What is the 'h' protocol? - -This is apparently used in some places with HST modems. It does no -error checking, and is not that different from the 't' protocol. I -don't know the details. - ------------------------------- - -From: UUCP-v -Subject: What is the 'v' protocol? - -The 'v' protocol is used by UUPC/extended, a PC UUCP program. It is -simply a version of the 'g' protocol which supports packets of any -size, and also supports sending packets of different sizes during the -same conversation. There are many 'g' protocol implementations which -support both, but there are also many which do not. Using 'v' ensures -that everything is supported. - ------------------------------- - -From: Thanks -Subject: Thanks - -Besides the papers and information acknowledged at the top of this -article, the following people have contributed help, advice, -suggestions and information: - Earle Ake 513-429-6500 <ake@Dayton.SAIC.COM> - cambler@nike.calpoly.edu (Christopher J. Ambler) - jhc@iscp.bellcore.com (Jonathan Clark) - jorge@laser.satlink.net (Jorge Cwik) - celit!billd@UCSD.EDU (Bill Davidson) - "Drew Derbyshire" <ahd@kew.com> - erik@pdnfido.fidonet.org - Matthew Farwell <dylan@ibmpcug.co.uk> - dgilbert@gamiga.guelphnet.dweomer.org (David Gilbert) - kherron@ms.uky.edu (Kenneth Herron) - Mike Ipatow <mip@fido.itc.e-burg.su> - Romain Kang <romain@pyramid.com> - "Jonathan I. Kamens" <jik@GZA.COM> - "David J. MacKenzie" <djm@eng.umd.edu> - jum@helios.de (Jens-Uwe Mager) - peter@xpoint.ruessel.sub.org (Peter Mandrella) - david nugent <david@csource.oz.au> - Stephen.Page@prg.oxford.ac.uk - joey@tessi.UUCP (Joey Pruett) - James Revell <revell@uunet.uu.net> - Larry Rosenman <ler@lerami.lerctr.org> - Rich Salz <rsalz@bbn.com> - evesg@etlrips.etl.go.jp (Gjoen Stein) - kls@ditka.Chicago.COM (Karl Swartz) - Dima Volodin <dvv@hq.demos.su> - jon@console.ais.org (Jon Zeeff) - Eric Ziegast <ziegast@uunet.uu.net> - ------------------------------- - -End of UUCP Internals Frequently Asked Questions -****************************** --- -Ian Taylor | ian@airs.com | First to identify quote wins free e-mail message: -``You don't have to sleep. That's just something *they* tell you to keep - *control* over you. Nobody has to sleep; you're *taught* to sleep when - you're a kid. If you're really determined, you can get over it.'' diff --git a/share/FAQ/Text/ctm.FAQ b/share/FAQ/Text/ctm.FAQ deleted file mode 100644 index 9dc0d050d5de..000000000000 --- a/share/FAQ/Text/ctm.FAQ +++ /dev/null @@ -1,191 +0,0 @@ -# ---------------------------------------------------------------------------- -# "THE BEER-WARE LICENSE" (Revision 42): -# <phk@login.dknet.dk> wrote this file. As long as you retain this notice you -# can do whatever you want with this stuff. If we meet some day, and you think -# this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp -# ---------------------------------------------------------------------------- -# -# $Id: ctm.FAQ,v 1.6 1995/03/16 22:03:09 phk Exp $ -# - - Obtaining FreeBSD-current sources using CTM. - ============================================ - -CTM is a method for keeping a remote directory tree in sync with a -central one. It has been developed for usage with FreeBSD's source -trees, though other people may find it useful for other purposes as -time goes by. Little, if any, documentation currently exists at this -time on the process of creating deltas so talk to phk@FreeBSD.org for -more information should you wish to use CTM for other things. - - -Why should I use CTM ? ----------------------- -CTM will give you a local copy of the "FreeBSD-current" sources. If -you are an active developer on FreeBSD, but have lousy or non-existent -TCP/IP connectivity, CTM was made for you. You will need to transfer -up to four deltas per day (or you can have them arrive in email -automatically), the sizes for which are always kept as small as -possible. This is typically less than 5K, with the occasional (one in -ten) being 10-50K and every now and then a biggie of 100K+ or more -coming around. - -You will also need to make yourself aware of the various caveats in -running "current" sources, and for this it is recommended that you -refer to the relevant FAQ: /usr/share/FAQ/current-policy.FAQ - - -What do I need to use CTM? --------------------------- - -You will need two things: The "ctm" program and the initial deltas to -feed it (to get up to "current" levels). - -The ctm program is in the FreeBSD-current tree from version 2.0.0 and -forward (/usr/src/usr.sbin/ctm). If you are running an older version -of FreeBSD, you can fetch the current ctm sources directly from: - - ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ctm/ - -The "deltas" you feed ctm can be had two ways, ftp or email. If you -have general ftp access to the Internet, then the following ftp sites -support access to CTM: - - ftp://freefall.cdrom.com/pub/CTM - -Ftp the the relevant directory and fetch the README file, starting -from there. - -If you only have access to electronic mail or are otherwise blocked -from using ftp, then you may wish to receive your deltas via email: - -Send email to majordomo@freebsd.org to subscribe to the list -"ctm-src-cur" (if you do not know how to subscribe yourself using -majordomo, send a message first containing the word `help' - it will -send you back usage instructions). - -When you begin receiving your CTM updates in the mail, you may use the -ctm_rmail program to unpack and apply them with. You can actually use -the ctm_rmail program directly from a entry in /etc/aliases if you -want. Check the "ctm_rmail" man page for more details. - -NOTE: ------ - -No matter what method you use to get the CTM deltas, you should subscribe -to the ctm-announce@freebsd.org mailing list. In the future this will be -the only place where announcements about the operation of the CTM system -will be posted. Send an email to majordomo@freebsd.org with a single -line of "subscribe ctm-announce" to get added to the list. - - -Starting off with CTM for the first time: ------------------------------------------ - -Before you can start using CTM deltas, you will need to get a special -"base" delta that provides a starting point for all deltas produced -subsequently to it. - -You can recognize a base delta by the 'A' appended to the number -(src-cur.0341A.gz for instance). As a rule a base delta is produced -every 100 deltas, the next one will be src-cur.0400A.gz. -By the way, they are large! 25 to 30 Megabytes of gzip'ed data is -common for a base delta. - -If you do have the 2.0-RELEASE srcdist, you can instead retreive the -src-cur.0372R20.gz file, it's only 4Mb and it will take you to current -from the 2.0-RELEASE sources. - -Once you've picked a base delta to start from, you will also need all -deltas with higher numbers following it. - - -Using CTM in your daily life: ------------------------------ - -To apply the deltas, simply say - - cd /where/ever/you/want/the/stuff - ctm -v -v /where/you/store/your/deltas/src-cur.* - -CTM understands deltas which have been put through gzip, so you don't -need to gunzip them first, this saves diskspace. - -Unless it feels very secure about the entire process, ctm will not -touch your tree. To check out a delta you can also use the "-c" flag -and CTM won't actually touch your tree, but only check the integrity -of the delta, and see if it would apply cleanly to the tree. - -There are other options to ctm as well, look in the sources. - -I would also be very happy if somebody could help with the "user -interface" portions, as I have realized that I can't make up my mind -on what options should do what, how and when... - -That's really all there is to it. Everytime you get a new delta, you -run it through ctm. - -Don't remove the deltas, if they are hard to download again. You just -might want to keep them around in case something bad happens. Even if -you only have floppy disks, consider using "fdwrite" to make a copy. - - -Plans: ------- - -Tons of them: - - - Make local modifications to the tree possible. One way to do it - could be this: - When CTM wants to edit the file "foo/bar.c", it would first check - for the existense of "foo/bar.c#ctm" If this file exists, the - delta is applied to it instead. This way the foo/bar.c file can - be edited to suit local needs. - - Make a "restore file(s)" option to ctm, something like: - ctm -r src/sys/i386/wd.c /here/are/my/deltas/src-cur.* - would restore wd.c to the current status from the files. - - Clean up the options to ctm, they became confusing and - counter intuitive. - -The bad news is that I am very busy, so any help in doing this will be -most welcome. And don't forget to tell me what you want also... - - -Misc. stuff: ------------- - -All the "DES infected" (e.g. export controlled) source is not included. -You will get the "international" version only. If sufficient interest -appears, we will set up a "sec-cur" sequence too. - -If you are a frequent or valuable contributor to FreeBSD, I will be -willing to arrange special services, one option is delivery via ftp or -rcp to a machine closer to you. You need to have earned this, since -it takes time to do, but I'll be all the more happy to do it for you -then. - -There is a sequence of deltas for the ports collection too, but interest -has not been all that high yet. Tell me if you want an email list for -that too and we'll consider setting it up. - -If you have commit priviledges or are similary authorized by the -FreeBSD core team, you can also get access to the CVS repository tree -by the same means. Contact me (phk@FreeBSD.org) for details. - - -Thanks! -------- - -Bruce Evans, for his pointed pen and invaluable comments. -Soren Schmidt, for patience. -Stephen McKay, wrote ctm_[rs]mail, much appreciated. -Jordan Hubbard, for being so stubborn that I had to make it better. -All the users, I hope you like it... - -Comments ? ----------- - -email phk@FreeBSD.org - - -Poul-Henning diff --git a/share/FAQ/Text/current-policy.FAQ b/share/FAQ/Text/current-policy.FAQ deleted file mode 100644 index dd61dbd50e0b..000000000000 --- a/share/FAQ/Text/current-policy.FAQ +++ /dev/null @@ -1,170 +0,0 @@ - THE FREEBSD CURRENT POLICY - -Last updated: $Date: 1995/02/27 08:25:50 $ - -This document attempts to explain the rationale behind FreeBSD-current, -what you should expect should you decide to run it, and states some -prerequisites for making sure the process goes as smoothly as possible. - - -1. What is FreeBSD-current? - -FreeBSD-current is, quite literally, nothing more than a daily snapshot of -the working sources for FreeBSD. These include work in progress, experimental -changes, and transitional mechanisms that may or may not be present in -the next official release of the software. While many of us compile -almost daily from FreeBSD-current sources, there are periods of time when -the sources are literally uncompilable. These problems are generally resolved -as expeditiously as possible, but whether or not FreeBSD-current sources bring -disaster or greatly desired functionality can literally be a matter of which -part of any given 24 hour period you grabbed them in! Please read on.. - -Under certain circumstances we will sometimes make binaries for parts of -FreeBSD-current available, but only because we're interested in getting -something tested, not because we're in the business of providing binary -releases of current. If we don't offer, please don't ask! It takes far -too much time to do this as a general task. - - -2. Who needs FreeBSD-current? - -FreeBSD-current is made generally available for 3 primary interest groups: - - 1. Members of the FreeBSD group who are actively working on one - part or another of the source tree and for whom keeping `current' - is an absolute requirement. - - 2. Members of the FreeBSD group who are active ALPHA/BETA testers - and willing to spend time working through problems in order to - ensure that FreeBSD-current remains as sane as possible. These - are also people who wish to make topical suggestions on changes - and the general direction of FreeBSD. - - 3. Peripheral members of the FreeBSD (or some other) group who merely - wish to keep an eye on things and use the current sources for - reference purposes (e.g. for *reading*, not running). These - people also make the occasional comment or contribute code. - - -3. What is FreeBSD-current _NOT_? - - 1. A fast-track to getting pre-release bits because there's something - you heard was pretty cool in there and you want to be the first on - your block to have it. - - 2. A quick way of getting bug fixes. - - 3. In any way "officially supported" by us. - - We do our best to help people genuinely in one of the 3 - "legitimate" FreeBSD-current catagories, but we simply DO NOT - HAVE THE TIME to help every person who jumps into FreeBSD-current - with more enthusiasm than knowledge of how to deal with - experimental system software. This is not because we're mean and - nasty people who don't like helping people out (we wouldn't even be - doing FreeBSD if we were), it's literally because we can't answer - 400 messages a day AND actually work on FreeBSD! I'm sure if - given the choice between having us answer lots of questions or - continue to improve FreeBSD, most of you would vote for us - improving it (and so would we! :-). - - -4. Ok. I still think I "qualify" for FreeBSD-current, so what do I do? - - 1. Join the freebsd-hackers and freebsd-commit mailing lists. - This is not just a good idea, it's ESSENTIAL. If you aren't on - freebsd-hackers, you won't read the comments that people are - making about the current state of the system and thus will end - up stumbling over a lot of problems that others have already - found and solved. Even more importantly, you will miss out on - potentially critical information (e.g. "Yo, Everybody! Before you - rebuild /usr/src, you MUST rebuild the kernel or your system - will crash horribly!"). - - The freebsd-commit list will allow you to see the commit log - entry for each change as its made. This can also contain - important information, and will let you know what parts of the - system are being actively changed. - - To join these lists, send mail to `majordomo@FreeBSD.ORG' - and say: - - subscribe freebsd-hackers - subscribe freebsd-commit - - In the body of your message. Optionally, you can also say `help' - and MajorDomo will send you full help on how to subscribe and - unsubscribe to the various other mailing lists we support. - - 2. Grab the sources from ftp.FreeBSD.ORG. You can do this in - three ways: - - 1. Using the CTM facility. Read the ctm.FAQ file for more - information. Unless you have a good TCP/IP connection at - a flat rate, this is the way to do it. - - 2. Use the CMU `sup' program (Software Update Protocol). - This is the second most recommended method, since it allows - you to grab the entire collection once and then only what's - changed from then on. Many people run sup from cron - and keep their sources up-to-date automatically. - - The problem is that sup does not use the bandwidth efficient, - unless the round-trip is very fast. If the cost of connection - or the duration of the session is a concern, use CTM. - - To get a binary of the sup program for FreeBSD, as well - as the documentation and some sample configuration files, - look in: - - FreeBSD.ORG:~ftp/pub/sup - - 3. Use ftp. The source tree for FreeBSD-current is always - "exported" on: - - ftp.FreeBSD.ORG:~ftp/pub/FreeBSD/FreeBSD-current - - We use `wu-ftpd' which allows compressed/tar'd grabbing - of whole trees. e.g. you see: - - usr.bin/lex - - You can do: - - ftp> cd usr.bin - ftp> get lex.tar.Z - - And it will get the whole directory for you as a compressed - tar file. - - 3. If you're grabbing the sources to run, and not just look at, - then grab ALL of current, not just selected portions. The - reason for this is that various parts of the source depend on - updates elsewhere and trying to compile just a subset is almost - guaranteed to get you into trouble. - - 4. Before compiling current, read the Makefile in /usr/src - carefully. You'll see one-time targets like `bootstrapld' - which *MUST* be run as part of the upgrading process. Reading - freebsd-hackers will keep you up-to-date on other bootstrapping - procedures that sometimes become necessary as we move towards - the next release. - - 5. Be active! If you're running FreeBSD-current, we want to know - what you have to say about it, especially if you have suggestions - for enhancements or bug fixes. Suggestions with accompanying code - are received most enthusiastically! :-) - - -Thank you for taking the time to read this all the way through. We're -always very keen to remain "open" and share the fruits of our labor -with the widest possible audience, but sharing development sources has -always had certain pitfalls associated with it (which is why most -commercial organizations won't even consider it) and I want to make -sure that people at least come into this with their eyes open, and -don't make the leap unless they're good at working without a net! - - Jordan - - - diff --git a/share/FAQ/Text/diskspace.FAQ b/share/FAQ/Text/diskspace.FAQ deleted file mode 100644 index b696f1cd1ac9..000000000000 --- a/share/FAQ/Text/diskspace.FAQ +++ /dev/null @@ -1,267 +0,0 @@ - How to assign disk space to FreeBSD. - -$Id: diskspace.FAQ,v 1.2 1995/01/03 15:54:02 gclarkii Exp $ - -1.0 Getting started. ---------------------- - -After a general introduction, you will find some explanation on what you -need to do to assign space to FreeBSD on your disk(s). This is done -through the "sysinstall" program, which lives on the inital boot floppy. -Those already expert with PCs may wish to skip ahead to section 1.2, the -rest of you may (or may not) enjoy the brief history lesson. - - -1.1 The ins and outs of allocating disk storage on your PC. ------------------------------------------------------------- - -Modern hard disk drives are now getting big enough that people don't want -to allocate all of one to just one operating system anymore, especially -given the increasing size of disk drives (the latest 9.0 Gbyte models -holding the equivalent of some six thousand 1.44MB floppies!) and the -virtual explosion of operating system options available for the PC. To -solve this problem, IBM came up with a scheme for "slicing" the disks -into more manageable chunks, or partitions. It works, but only just. -To better understand why, first a brief bit of history: - -MS-DOS, when hard disk support was unceremoniously grafted on back in the -late eighties, didn't have such "slices". What it had was a way to install -Xenix and MS-DOS on the same disk (Remember when Microsoft were in the UNIX -business?). - -In the first sector on the disk was a piece of "primary boot code" and a -table with four entries. Each of those entries pointed at an arbitrary -slice of the disk, with one of them was marked "active". The machine would -boot by reading the first sector containing the boot code into RAM and then -jumping to it. The job of this small piece of boot code was to look at -the 4 entry table and decide which OS was to be booted by looking -for the "active" flag. It would go and load the first sector of that slice -of the disk into RAM and then and jump to it in turn. This bit of boot -code was called the "secondary boot", and could be specific to a given -operating system. The primary boot code and 4-entry table is known -as the Master Boot Record, or MBR, and is very important to the proper -operation of your PC! We will discuss the MBR in more detail later. - -It was later realized, with the hindsight that IBM is famous for, that disks -could be bigger than the 32Mb that the early DOS FAT-12 file system could -handle, so they added a kludge: They had two MSDOS slices, a "Primary" and -a "Secondary". The primary could still only be 32Mb, but the Secondary had -no size limit. And the trick was that the secondary had ANOTHER "table -entry" so that now suddenly up to 5 slices could be available to MS-DOS. -The Secondary boot record was later made recursive, thus effectively -avoiding any fixed limit. Of course, they were still stuck with a maximum -of 26 slices given the use of "drive letters" in DOS. They also reserved -only 10 bits for cylinder addressing, limiting DOS to being able to address -a maximum of 1024 cylinders (and cause of the dreaded "cylinder translation" -kludges, the misconfiguration of which many users have seen as the notorious -"Missing Operating System" message). Yes, truly DOS was and is an utterly -terrible operating system, which of course explains its amazing degree of -success. Anyway, this all brings us up to today, which is where FreeBSD -comes in: - - -1.2 What FreeBSD does ----------------------- -FreeBSD has, like any other UNIX-like operating system, the concept of -"partitions." Partitions are used to implement its own "slicing" -abstraction, and although there is no real difference between a slice and a -partition as such, we use the two words to distinguish between these two -different levels of slicing. - -The result is that we have a two-tier structure on the disk: - -+-----------+ -| MBR-table | -+-----------+ +---------+ -| Slice 1 | -----> | MSDOS | -+-----------+ +---------+ -| Slice 2 | -+-----------+ +-------------------+ -| Slice 3 | -----> | FreeBSD-disklabel | -+-----------+ +-------------------+ +-----------------+ -| Slice 4 | | Partition A | -----> | Root-filesystem | -+-----------+ +-------------------+ +-----------------+ - | Partition B | --- - +-------------------+ \ +----------------+ - | Partition C | --> | swap-partition | - +-------------------+ +----------------+ - | ... | - - -Here are the rules that FreeBSD plays by: - -A: FreeBSD always has an MBR slice with type 0xa5 (each of the 4 slices can - also have a unique integer identifier so you can tell your DOS slices - from your FreeBSD slices from your Linux slices, etc). This means that - there should always be an MBR record, even in the case where FreeBSD - occupies the entire disk. -B: The FreeBSD slice contains the FreeBSD disklabel in the second sector - (remember, the first sector contains the secondary boot code for FreeBSD, - which is what prints that FreeBSD prompt at you when you first boot - FreeBSD from a floppy or hard disk). -C: The 'C' partition in the FreeBSD disklabel corresponds to the entire - FreeBSD slice. -D: The 'D' partition corresponds to the entire physical disk. -E: Should a disk not have a FreeBSD slice (because there simply is no - FreeBSD on it anywhere), then the MBR slices are mapped into partitions - 'E' to 'H' of an artificially created FreeBSD disklabel. This is useful - for getting at DOS-only disks. - -Therefore, to get FreeBSD onto your disk, you need to do the following: - - Step FreeBSD utility - ------------------------------------------------------------ --------------- - 1. Make an MBR slice for FreeBSD (FDISK) - 2. Partition the diskspace in the MBR slice into partitions (DISKLABEL) - 3. Assign mountpoints to the partitions. (DISKLABEL) - - - -2. The sysinstall utility --------------------------- - -The sysinstall utility is the program you first see when you boot -FreeBSD's install floppy. It is responsible for partitioning your -disk, creating an MBR slice for FreeBSD, setting up the disklabel -within that slice and creating filesystems for each FreeBSD partition -you create within that slice. It is composed of a number of screens. -These are described below. - - -2.1 The main screen --------------------- -The main screen shows you the current status, It shows you which disks -FreeBSD has found, how big they are and how much of it is assigned to -FreeBSD in a FreeBSD MBR slice. It also shows the partitions which have -had a mountpoint assigned to them (not necessarily FreeBSD partitions; -FreeBSD is perfectly capable of mounting DOS disks directly). - -(H)elp -- shows you this file. - -(F)disk -- enters the Fdisk editor, where you can change the MBR record. - This is what you want to use to assign some part of the disk to FreeBSD. - -(D)isklabel -- enters the Disklabel editor, here you can change how the - FreeBSD slice is partitioned for FreeBSD. - -(P)rocede -- will continue the installation process. - -(Q)uit -- Go back to the entry screen. - - -2.2 FDISK - how to make an MBR slice -------------------------------------- -There are some rules to follow here since altering your MBR is a potential -minefield. There is really no way for the sysinstall program to genuinely -know that you have a valid MBR, so you have to be extra careful in what -you edit. Failure to do this properly can and will destroy your other -operating system entries! - -Even if you don't plan to have MSDOS on a disk, make an MSDOS slice -using the MSDOS's FDISK.COM program. The reason for this is that if you -do it that way, you are 100% sure that FreeBSD will use the same number -of heads, sectors and cylinders as MSDOS would use. If you really don't -plan to have MSDOS on the disk, just (D)elete the slice in the FreeBSD's -(F)disk editor. - -From the main screen press 'F' to enter the MBR editor. You have five -commands available: - -(H)elp -- Shows you this file. - -(D)elete -- Deletes a slice entirely. - -(E)dit -- Allows you to edit a slice. It will ask how many megabytes - you want to assign to the slice, and will suggest the maximum possible - as a default. It might say zero, even though there is disk space - available, in which case you will probably need to delete and recreate the - other partitions to get it to see where the free space is. - It will then ask you what type to give the slice, for which the default is - 0xa5 (a FreeBSD slice). You can enter any other number here too, which - can be useful as a placeholder for some other OS you plan to install - later. Finally, it will ask you about the "boot flag". 0x80 means "boot - from this" slice by default, and anything else means "don't". - - If you specified a FreeBSD slice, any existing slices with the 0xa5 - type will be reset to 0x00 "unused". FreeBSD only supports one slice - per disk for FreeBSD. - -(R)eread -- This is your "undo" function. It will read the data of the - disk again, disposing of any changes you may have made. - -(W)rite -- When you are satisfied with the data, this function will write - the new MBR to the disk. - -(Q)uit -- Go back to the main screen. - - -2.3 Disklabel - How to divide up the FreeBSD slice. ----------------------------------------------------- - -The disklabel screen provides the following commands: - -(H)elp -- Shows you this file. - -(S)ize -- Resizes a partition for you, it will suggest as a default the - maximum amount of diskspace it can find. This algorithm isn't too smart - and may say zero, even though there is diskspace available. If it - does, delete and resize the other partitions. - -(A)ssign -- Here you assign where the filesystem in a partition is to - be mounted. `b' partitions will always be made into "swap" partitions. - -(D)elete -- Delete a partition. - -(R)eread -- The undo function. It will reread the current disklabel from - the kernel. - -(W)rite -- This will write the disklabel to the disk. You must always write - before you quit, otherwise your changes will be lost. - -(Q)uit -- Exit back to the main screen. - - -2.4. Hints on partition sizing -------------------------------- - -While it's impossible to say how much space you're going to want to -make your various partitions without knowing more about your intended -applicatins, here are some good rules of thumb to follow: - -1. Root (/) should be at least 18MB, and probably no more than 50MB unless - you have some special reason for making your root partition really - large. Remember that the root filesystem is only supposed to contain - vital system files and little else. - -2. Swap should be at least 2*memory. That is to say if you have 8MB of - memory, then you probably want 16MB of swap. Even more swap space - certainly doesn't hurt, if you can afford to allocate it, and you should - also think ahead a little to any planned memory upgrades you may have - in mind since increasing this later can be very painful! - - If you're going to run the X Window System (XFree86), you should also - consider having a *minimum* of 16MB of swap, since X tends to really - use it up. - -3. /usr can take up the rest of your disk, though some people like to create - extra partitions for user home directories and the like. Be sure to make - your /usr big enough to contain the system software (about 50MB) and - perhaps some of your own, unless you're going to use symbolic links to - point things like /usr/local (or /usr/src) somewhere else. - - -Here are some suggested filesystem names and sizes, just for reference: - -Mountpoint Filesystem size -------------------------------- -/var 10Mb -/usr 50Mb -/ 16Mb - -/usr/src 120Mb If you want to have the sources online -/usr/obj 100Mb If you want to compile all of them at one time - -/usr/X11R6 50Mb If you load the entire XFree86 binary kit. - - -$Id: diskspace.FAQ,v 1.2 1995/01/03 15:54:02 gclarkii Exp $ diff --git a/share/FAQ/Text/kernel-debug.FAQ b/share/FAQ/Text/kernel-debug.FAQ deleted file mode 100644 index 304bcd367c6f..000000000000 --- a/share/FAQ/Text/kernel-debug.FAQ +++ /dev/null @@ -1,417 +0,0 @@ -# Hello emacs, this is -*- indented-text -*- - - Kernel debugging FAQ for FreeBSD - -$Id: kernel-debug.FAQ,v 1.3 1995/07/30 12:53:39 joerg Exp $ - - -*** Debugging a kernel crash dump with kgdb *** - - [In the following, the term ``kgdb'' refers to gdb run in `kernel - debug mode'. This can be accomplished by either starting the gdb - with the option ``-k'', or by linking and starting it under the - name ``kgdb''. This is not being done by default, however.] - - Here are some instructions for getting kernel debugging working on a - crash dump, it assumes that you have enough swap space for a crash - dump. If you happen to have multiple swap partitions with the first - one being too small to keep the dump, you can configure your kernel - to use an alternate dump device (in the ``config kernel'' line), or - you can tell this using the dumpon(8) command. Dumps to non-swap - devices (e.g. tapes) are currently not supported. - - Config your kernel using config -g - - Either, use the dumpon(8) command to tell the kernel where to dump - to (note that this will have to be done after configuring the - partition in question as swap space via swapon(8)). This is - normally arranged via sysconfig and /etc/rc. Alternatively, you can - hard-code the dump device via the `dump' clause in the `config' line - of your kernel config file. - - When the kernel's been built make a copy of it, say kernel.debug, - and then run strip -x on the original. Install the original as - normal. You may also install the unstripped kernel, but symtab - lookup time for some programs might drastically increase, and since - the whole kernel is loaded entirely at boot time and cannot be - swapped out later, you're going to waste several megabytes of - physical RAM. - - If you are testing a new kernel (e.g. by typing the new kernel's - name at the boot prompt), but need to boot a different one in order - to get your system up & running again, do boot it only into single - user state (the -s flag at the boot prompt), and then perform the - following steps: - - fsck -p - mount -a -t ufs # so your file system for /var/crash is writable - savecore -N /kernel.panicked /var/crash - exit # ...to multi-user - - This instructs savecore to use another kernel for symbol name - extraction; it would default to the currently running kernel - otherwise. - - Now, after a crash dump, go to /sys/compile/WHATEVER and run - kgdb. From kgdb do: - - symbol-file kernel.debug - exec-file /var/crash/system.0 - core-file /var/crash/ram.0 - - and voila, you can debug the crash dump using the kernel sources - just like you can for any other program. - - If your kernel panicked due to a trap (perhaps the most common case - for getting a core dump), the following trick might help you. Examine - the stack (`where') and look for the stack frame in the function - trap(). Go `up' to that frame, and then type: - - frame frame->tf_ebp frame->tf_eip - - This will tell kgdb to go to the stack frame explicitly named by a - frame pointer and instruction pointer, which is the location where - the trap occured. There are still some bugs in kgdb (you can go - `up' from there, but not `down'; the stack trace will still remain - as it was before going to here), but generally this method will lead - you much closer to the failing piece of code. - - Here's a script log of a kgdb session illustrating the above. Long - lines have been folded to improve readability, and the lines are - numbered for reference. Despite of this, it's a real-world error - trace taken during the development of the pcvt console driver. - - 1:Script started on Fri Dec 30 23:15:22 1994 - 2:uriah # cd /sys/compile/URIAH - 3:uriah # kgdb kernel /var/crash/vmcore.1 - 4:Reading symbol data from /usr/src/sys/compile/URIAH/kernel...done. - 5:IdlePTD 1f3000 - 6:panic: because you said to! - 7:current pcb at 1e3f70 - 8:Reading in symbols for ../../i386/i386/machdep.c...done. - 9:(kgdb) where - 10:#0 boot (arghowto=256) (../../i386/i386/machdep.c line 767) - 11:#1 0xf0115159 in panic () - 12:#2 0xf01955bd in diediedie () (../../i386/i386/machdep.c line 698) - 13:#3 0xf010185e in db_fncall () - 14:#4 0xf0101586 in db_command (-266509132, -266509516, -267381073) - 15:#5 0xf0101711 in db_command_loop () - 16:#6 0xf01040a0 in db_trap () - 17:#7 0xf0192976 in kdb_trap (12, 0, -272630436, -266743723) - 18:#8 0xf019d2eb in trap_fatal (...) - 19:#9 0xf019ce60 in trap_pfault (...) - 20:#10 0xf019cb2f in trap (...) - 21:#11 0xf01932a1 in exception:calltrap () - 22:#12 0xf0191503 in cnopen (...) - 23:#13 0xf0132c34 in spec_open () - 24:#14 0xf012d014 in vn_open () - 25:#15 0xf012a183 in open () - 26:#16 0xf019d4eb in syscall (...) - 27:(kgdb) up 10 - 28:Reading in symbols for ../../i386/i386/trap.c...done. - 29:#10 0xf019cb2f in trap (frame={tf_es = -260440048, tf_ds = 16, tf_\ - 30:edi = 3072, tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\ - 31:2630396, tf_ebx = -266427884, tf_edx = 12, tf_ecx = -266427884, tf\ - 32:_eax = 64772224, tf_trapno = 12, tf_err = -272695296, tf_eip = -26\ - 33:6672343, tf_cs = -266469368, tf_eflags = 66066, tf_esp = 3072, tf_\ - 34:ss = -266427884}) (../../i386/i386/trap.c line 283) - 35:283 (void) trap_pfault(&frame, FALSE); - 36:(kgdb) frame frame->tf_ebp frame->tf_eip - 37:Reading in symbols for ../../i386/isa/pcvt/pcvt_drv.c...done. - 38:#0 0xf01ae729 in pcopen (dev=3072, flag=3, mode=8192, p=(struct p\ - 39:roc *) 0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c line 403) - 40:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); - 41:(kgdb) list - 42:398 - 43:399 tp->t_state |= TS_CARR_ON; - 44:400 tp->t_cflag |= CLOCAL; /* cannot be a modem (:-) */ - 45:401 - 46:402 #if PCVT_NETBSD || (PCVT_FREEBSD >= 200) - 47:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); - 48:404 #else - 49:405 return ((*linesw[tp->t_line].l_open)(dev, tp, flag)); - 50:406 #endif /* PCVT_NETBSD || (PCVT_FREEBSD >= 200) */ - 51:407 } - 52:(kgdb) print tp - 53:Reading in symbols for ../../i386/i386/cons.c...done. - 54:$1 = (struct tty *) 0x1bae - 55:(kgdb) print tp->t_line - 56:$2 = 1767990816 - 57:(kgdb) up - 58:#1 0xf0191503 in cnopen (dev=0x00000000, flag=3, mode=8192, p=(st\ - 59:ruct proc *) 0xf07c0c00) (../../i386/i386/cons.c line 126) - 60: return ((*cdevsw[major(dev)].d_open)(dev, flag, mode, p)); - 61:(kgdb) up - 62:#2 0xf0132c34 in spec_open () - 63:(kgdb) up - 64:#3 0xf012d014 in vn_open () - 65:(kgdb) up - 66:#4 0xf012a183 in open () - 67:(kgdb) up - 68:#5 0xf019d4eb in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =\ - 69: 2158592, tf_esi = 0, tf_ebp = -272638436, tf_isp = -272629788, tf\ - 70:_ebx = 7086, tf_edx = 1, tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \ - 71:tf_err = 582, tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \ - 72:= -272638456, tf_ss = 39}) (../../i386/i386/trap.c line 673) - 73:673 error = (*callp->sy_call)(p, args, rval); - 74:(kgdb) up - 75:Initial frame selected; you cannot go up. - 76:(kgdb) quit - 77:uriah # exit - 78:exit - 79: - 80:Script done on Fri Dec 30 23:18:04 1994 - - Comments to the above script: - - line 6: this is a dump taken from within DDB (see below), hence the - panic comment ``because you said to!'', and a rather long - stack trace; the initial reason for going into DDB has been - a page fault trap though - - line 20: the location of function ``trap()'' in the stack trace - - line 36: force usage of a new stack frame, kgdb responds and displays - the source line where the trap happened; from looking at the - code, there's a high probability that either the pointer - access for ``tp'' was messed up, or the array access was - out of bounds - - line 52: the pointer looks suspicious, but happens to be a valid - address... - - line 56: ... but obviously points to garbage, so we have found our - error, sigh! [For those uncommon with that particular piece - of code: tp->t_line refers to the line discipline of the - console device here, which must be a rather small integer - number.] - - - -*** Post-mortem analysis of a dump *** - - What to do if a kernel dumped core but you didn't expect it, and it's - therefore not compiled using config -g? - - Not everything is lost here. Don't panic. :-) - - Of course, you still need to enable crash dumps at all. See above - on the options you've got to do this. (This is for safety reasons - in the default kernels, to avoid them trying to dump e.g. during - system installation where there's no FreeBSD partition at all and - valuable data on the disk could be destroyed.) - - Go to your kernel compile directory, and edit the line containing - COPTFLAGS?=-O. Add the `-g' option there (but DON'T change anything - on the level of optimization). If you do already know roughly the - probable location of the failing piece of code (e.g., the `pcvt' - driver in the example above), remove all the object files for this - code. Rebuild the kernel. Due to the time stamp change on the - Makefile, there will be some other object files rebuild, e.g. - trap.o. With a bit of luck, the added -g option won't change - anything for the generated code, so you'll finally get a new kernel - with similiar code to the faulting one but some debugging symbols. - You should at least verify the old and new sizes with the `size' - command; if they mismatch, you probably need to give up here. - - Go and examine the dump as described above. The debugging symbols - might be incomplete for some places (as can be seen in the stack trace - in the example above: some functions are displayed without line - numbers and argument lists). If you need more debugging symbols, - remove the appropriate object files and repeat the kgdb session until - you know enough. - - All this is not guaranteed to work, but most likely will do it fine. - - - -*** On-line kernel debugging using DDB *** - - While kgdb as an offline debugger provides a very high level of user - interface (e.g. it can lookup source files, display C structures - etc.), there are some things it cannot do. The most important ones - being breakpointing and single-stepping kernel code. - - If you need to do low-level debugging on your kernel, there's an on- - line debugger available called DDB. It allows to set breakpoints, - single-step kernel functions, examine and change kernel variables - etc. It can however not access kernel source files, and it does - only have access to the global and static symbols, but not to the - full debug information (including type and line number information) - like kgdb. - - To configure your kernel to include DDB, add the option line - - options DDB - - to your config file, and rebuild. - - (Note that if you have an older version of the boot blocks, your - debugger symbols might not be loaded at all. Update the boot - blocks, the recent ones do load the DDB symbols automagically.) - - Once your DDB kernel is running, there are several ways to enter - DDB. The first (and most early) way is to set the boot flag `-d' - (right at the boot prompt). The kernel will start up in debug mode - and enter DDB prior to any device probing. Hence you are able to - even debug the device probe/attach functions. - - The second scenario is a hot-key on the keyboard, usually Ctrl-Alt- - ESC. (For syscons, this can be remapped, and some of the - distributed maps do this, so watch out.) There's an option - available for a COMCONSOLE kernel (``options BREAK_TO_DEBUGGER'') - that allows the use of a serial line BREAK on the console line to - enter DDB. - - The third way is that any panic condition will branch to DDB if the - kernel is configured to use it. (Thus it is not wise to configure a - kernel with DDB for a machine running unattended.) - - - The DDB commands roughly resemble some gdb commands. The first you - probably need is to set a breakpoint: - - b function-name - b address - - Numbers are taken hexadecimal by default, but to make them distinct - from symbol names, hex numbers starting with the letters `a' - `f' - need to be preceded with `0x' (for other numbers, this is optional). - Simple expressions are allowed, e.g. ``function-name + 0x103''. - - To continue the operation of an interrupted kernel, simply type - - c - - To get a stack trace, use - - trace - - Note that when entering DDB via a hot-key, the kernel is currently - servicing an interrupt, so the stack trace might be not of much use - for you. - - If you want to remove a breakpoint, use - - del - del address-expression - - The first form will be accepted immediately after a breakpoint hit, - and deletes the current breakpoint. The second form can remove any - breakpoint, but you need to specify the exact address, as it can be - obtained from - - show b - - To single-step the kernel, try - - s - - This will step into functions, but you can make DDB trace them until - the matching return statement is reached by - - n - - NOTE: this is different from gdb's ``next'' statement, it's like - gdb's ``finish''. - - To examine data from memory, use e.g. - - x/wx 0xf0133fe0,40 - x/hd db_symtab_space - x/bc termbuf,10 - x/s stringbuf - - for word/halfword/byte access, and hexadecimal/decimal/character/ - string display. The number after the comma is the object count. - To display the next 0x10 items, simply use - - x ,10 - - Similiarly, use - - x/ia foofunc,10 - - to disassemble the first 0x10 instructions of foofunc, and display - them along with their offset from the beginning of foofunc. - - To modify the memory, use the write command: - - w/b termbuf 0xa 0xb 0 - w/w 0xf0010030 0 0 - - The command modifier (b/h/w) specifies the size of the data to be - writtten, the first following expression is the address to write to, - the remainder is interpreted as data to write to successive memory - locations. - - If you need to know the current registers, use - - show reg - - Alternatively, you can display a single register value by e.g. - - print $eax - - and modify it by - - set $eax new-value - - - Should you need to call some kernel functions from DDB, simply - say - - call func(arg1, arg2, ...) - - The return value will be printed. - - For a ps-style summary of all running processes, use - - ps - - - - Well, you've now examined why your kernel failed, and you wish to - reboot. Remember that, depending on the severity of previous - malfunctioning, not all parts of the kernel might still be working - as expected. Perform one of the following actions to shut down and - reboot your system: - - - call diediedie() - - (must usually be followed by another ``c[ontinue]'' statement), - will cause your kernel to dump core and reboot, so you can later - analyze the core on a higher level with kgdb. - - There's now an alias for this: ``panic''. - - - call boot(0) - - might be a good way to cleanly shut down the running system, sync() - all disks, and finally reboot. As long as the disk and file system - interfaces of the kernel are not damaged, this might be a good way - for an almost clean shutdown. - - - call cpu_reset() - - ...is the final way out of the desaster, almost similiar to hitting - the Big Red Button. - - - -*** What to do if i want to debug a console driver? *** - - Since you need a console driver to run DDB on, things are more - complicated if the console driver itself is flakey. You might - remember the ``options COMCONSOLE'' line, and hook up a standard - terminal onto your first serial port. DDB works on any configured - console driver, of course it also works on a COMCONSOLE. - - - - Paul Richards, FreeBSD core team member. (paul@FreeBSD.org) - J"org Wunsch (joerg@FreeBSD.org) - diff --git a/share/FAQ/Text/kernel-memory.FAQ b/share/FAQ/Text/kernel-memory.FAQ deleted file mode 100644 index 79ab09acf6c1..000000000000 --- a/share/FAQ/Text/kernel-memory.FAQ +++ /dev/null @@ -1,72 +0,0 @@ -~From: J Wunsch <j@uriah.heep.sax.de> -~Message-Id: <199504160843.KAA16160@uriah.heep.sax.de> -~Subject: Memory usage (Was Re: Memory init pattern) -~To: freebsd-hackers@FreeBSD.org (FreeBSD hackers) -~Date: Sun, 16 Apr 1995 10:43:29 +0200 (MET DST) - -[Audience extended to -hackers, since it's a general topic.] - -As Frank Durda IV wrote: -> -> By the way, I have seen no description of how FreeBSD uses PC memory, ie -> what 0-640K gets used for, does the kernel load there or higher, -> is the kernel relocated, etc. Is there a paper on this? - -Since i've just digged through the boot code, i can tell you what's -going there. :) [Someone going to collect this sort of messages -and making a kernel hackers manual?] - -The boot sector will be loaded at 0:0x7c00, and relocates itself -immediately to 0x7c0:0. (This is nothing magic, just an adjustment -for the %cs selector, done by an ljmp.) - -It then loads the first 15 sectors at 0x10000 (segment BOOTSEG in the -biosboot Makefile), and sets up the stack to work below 0x1fff0. -After this, it jumps to the entry of boot2 within that code. I.e., it -jumps over itself and the (dummy) partition table, and it's going to -adjust the %cs selector -- we are still in 16-bit mode there. - -boot2 asks for the boot file, and examines the a.out header. It masks -the file entry point (usually 0xf0100000) by 0x00ffffff, and loads the -file there. Hence the usual load point is 1 MB (0x00100000). During -load, the boot code toggles back and forth between real and protected -mode, to use the BIOS in real mode. - -The boot code itself uses segment selectors 0x18 and 0x20 for %cs and -%ds/%es in protected mode, and 0x28 to jump back into real mode. The -kernel is finally started with %cs 0x08 and %ds/%es/%ss 0x10, which -refer to dummy descriptors covering the whole address space. - -The kernel will be started at its load point. Since it's been linked -for another (high) address, it will have to execute PIC until the page -table and page directory stuff is setup properly, at which point -paging will be enabled and the kernel finally runs at the address -where it has been linked to. - -[... -- no longer valid] - -The later memory usage (once paging is enabled) could better be -explained by the VM folks. - --- -cheers, J"org - -joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -Never trust an operating system you don't have sources for. ;-) - -~Message-Id: <199504160955.CAA00143@corbin.Root.COM> -~To: freebsd-hackers@FreeBSD.org (FreeBSD hackers) -~Subject: Re: Memory usage (Was Re: Memory init pattern) -~From: David Greenman <davidg@Root.COM> -~Date: Sun, 16 Apr 1995 02:55:50 -0700 - -... - The physical pages immediately following the kernel BSS contain proc0's page -directory, page tables, and upages. Some time later when the VM system is -initialized, the physical memory between 0x1000-0x9ffff and the physical memory -after the kernel (text+data+bss+proc0 stuff+other misc) is made available in -the form of general VM pages and added to the global free page list. - Does this answer the question? - --DG - diff --git a/share/FAQ/Text/mailing-list.FAQ b/share/FAQ/Text/mailing-list.FAQ deleted file mode 100644 index 881890f64dc6..000000000000 --- a/share/FAQ/Text/mailing-list.FAQ +++ /dev/null @@ -1,105 +0,0 @@ - THE FREEBSD MAILING LIST FAQ - -$Id: mailing-list.FAQ,v 1.5 1995/01/03 15:54:04 gclarkii Exp $ - --- -Though many of the FreeBSD development members read USENET, we cannot -always guarantee that we'll get to your questions in a timely fashion -(or at all) if you post them only to one of the comp.os.386bsd.* -groups. By addressing your questions to the appropriate mailing list -you will reach both us and a concentrated FreeBSD audience, invariably -assuring a better (or at least faster) response. - -The following is a summary of the mailing lists: - -List Purpose ------------------------------------------------------------------------------ -freebsd-admim Administrative issues (limited) -freebsd-arch Architecture and design discussions (limited) -freebsd-bugs Bug reports -freebsd-hackers Technical discussions and suggestions -freebsd-questions User questions -freebsd-announce Important events / milestones -freebsd-current Discussions about the use of FreeBSD-current -freebsd-commit Commit messages to source repository -freebsd-core FreeBSD core team (limited) -freebsd-security Security issues -freebsd-fs Filesystems -freebsd-ports Discussion of "ports" -freebsd-platforms Porting to Non-Intel platforms -freebsd-hardware General discussion of FreeBSD hardware -freebsd-install Installation issues (limited) - ------------------------------------------------------------------------------ - -The following lists are for people seeing the log messages for source changes -in specific areas: - -List name Source area Area Description (source for) ------------------------------------------------------------------------------ -cvs-CVSROOT /usr/src/[A-Z]* Top level /usr/src file changes -cvs-all /usr/src All changes to the tree (superset) -cvs-bin /usr/src/bin System binaries -cvs-etc /usr/src/etc System files -cvs-games /usr/src/games Games -cvs-gnu /usr/src/gnu GPL'd utilities -cvs-include /usr/src/include Include files -cvs-kerberosIV /usr/src/kerberosIV Kerberos encryption code -cvs-lib /usr/src/lib System libraries -cvs-libexec /usr/src/libexec System binaries -cvs-sbin /usr/src/sbin System binaries -cvs-share /usr/src/share System shared files -cvs-sys /usr/src/sys Kernel -cvs-usrbin /usr/src/usr.bin Use binaries -cvs-usrsbin /usr/src/usr.sbin System binaries -cvs-ports /usr/ports Ported software ------------------------------------------------------------------------------ - -Even though the lists freebsd-core, freebsd-admin, freebsd-install and -freebsd-arch are closed, anyone is free to send suggestions and comments -to them. All other lists are open. - -All mailing lists live on `FreeBSD.ORG', so to post to a list you -simply mail to `<listname>@FreeBSD.ORG'. It will then be redistributed -to mailing list members throughout the world. - -To subscribe to a list, send mail to: - - majordomo@FreeBSD.ORG - -And include the keyword - - subscribe <listname> [<optional address>] - -In the body of your message. For example, to subscribe yourself to -freebsd-hackers, you'd do: - - % mail majordomo@FreeBSD.ORG - subscribe freebsd-hackers - ^D - -If you want to subscribe yourself under a different name, or submit a -subscription request for a local mailing list (note: this is more efficient -if you have several interested parties at one site, and highly appreciated by -us!), you would do something like: - - % mail majordomo@FreeBSD.ORG - subscribe freebsd-hackers local-hackers@somesite.com - ^D - -Finally, it is also possible to unsubscribe yourself from a list, get a -list of other list members or see the list of mailing lists again by -sending other types of control messages to majordomo. For a complete -list of available commands, do this: - - % mail majordomo@FreeBSD.ORG - help - ^D - -Finally, it is suggested that you only join the freebsd-hackers or -freebsd-questions mailing lists if you're also willing to see upwards -of 100 messages a day (peak)! If you're only interested in the "high points", -then it's suggested that you join freebsd-announce, which will contain -only infrequent traffic. - - Thank you! diff --git a/share/FAQ/Text/nfs.FAQ b/share/FAQ/Text/nfs.FAQ deleted file mode 100644 index 88c5fc568eba..000000000000 --- a/share/FAQ/Text/nfs.FAQ +++ /dev/null @@ -1,79 +0,0 @@ -FreeBSD and NFS [for a FAQ] - -$Id: nfs.FAQ,v 1.2 1995/01/03 15:54:05 gclarkii Exp $ - -Certain Ethernet adapters for ISA PC systems have limitations which -can lead to serious network problems, particularly with NFS. This -difficulty is not specific to FreeBSD, but FreeBSD systems are affected -by it. - -The problem nearly always occurs when (FreeBSD) PC systems are networked -with high-performance workstations, such as those made by Silicon Graphics, -Inc., and Sun Microsystems, Inc. The NFS mount will work fine, and some -operations may succeed, but suddenly the server will seem to become -unresponsive to the client, even though requests to and from other systems -continue to be processed. This happens to the client system, whether the -client is the FreeBSD system or the workstation. On many systems, there is -no way to shut down the client gracefully once this problem has manifested -itself. The only solution is often to reset the client, because the NFS -situation cannot be resolved. - -Though the "correct" solution is to get a higher performance and capacity -Ethernet adapter for the FreeBSD system, there is a simple workaround that -will allow satisfactory operation. If the FreeBSD system is the SERVER, -include the option "wsize=1024" on the mount from the client. If the -FreeBSD system is the CLIENT, then mount the NFS file system with the -option "rsize=1024". These options may be specified using the fourth -field of the fstab entry on the client for automatic mounts, or by using -the "-o" parameter of the mount command for manual mounts. - -In the following examples, "fastws" is the host (interface) name of a -high-performance workstation, and "freebox" is the host (interface) name of -a FreeBSD system with a lower-performance Ethernet adapter. Also, -"/sharedfs" will be the exported NFS filesystem (see "man exports"), and -"/project" will be the mount point on the client for the exported file -system. In all cases, note that additional options, such as "hard" or -"soft" and "bg" may be desireable in your application. - -Examples for the FreeBSD system ("freebox") as the client: - in /etc/fstab on freebox: -fastws:/sharedfs /project nfs rw,rsize=1024 0 0 - as a manual mount command on freebox: -mount -t nfs -o rsize=1024 fastws:/sharedfs /project - -Examples for the FreeBSD system as the server: - in /etc/fstab on fastws: -freebox:/sharedfs /project nfs rw,wsize=1024 0 0 - as a manual mount command on fastws: -mount -t nfs -o wsize=1024 freebox:/sharedfs /project - -Nearly any 16-bit Ethernet adapter will allow operation without the above -restrictions on the read or write size. - -For anyone who cares, here is what happens when the failure occurs, which -also explains why it is unrecoverable. NFS typically works with a "block" -size of 8k (though it may do fragments of smaller sizes). Since the maximum -Ethernet packet is around 1500 bytes, the NFS "block" gets split into -multiple Ethernet packets, even though it is still a single unit to the -upper-level code, and must be received, assembled, and ACKNOWLEDGED as a -unit. The high-performance workstations can pump out the packets which -comprise the NFS unit one right after the other, just as close together as -the standard allows. On the smaller, lower capacity cards, the later -packets overrun the earlier packets of the same unit before they can be -transferred to the host and the unit as a whole cannot be reconstructed or -acknowledged. As a result, the workstation will time out and try again, -but it will try again with the entire 8K unit, and the process will be -repeated, ad infinitum. - -By keeping the unit size below the Ethernet packet size limitation, we -ensure that any complete Ethernet packet received can be acknowledged -individually, avoiding the deadlock situation. - -Overruns may still occur when a high-performance workstations is slamming -data out to a PC system, but with the better cards, such overruns are -not guarranteed on NFS "units". When an overrun occurs, the units affected -will be retransmitted, and there will be a fair chance that they will be -received, assembled, and acknowledged. --- - John Lind, Starfire Consulting Services -E-mail: john@starfire.MN.ORG USnail: PO Box 17247, Mpls MN 55417 diff --git a/share/FAQ/Text/ports.FAQ b/share/FAQ/Text/ports.FAQ deleted file mode 100644 index 2a447add8751..000000000000 --- a/share/FAQ/Text/ports.FAQ +++ /dev/null @@ -1,246 +0,0 @@ - The FreeBSD Ports FAQ file - -Revision: $Id: ports.FAQ,v 1.2 1995/01/06 19:24:13 gpalmer Exp $ - -The ports system is kinda new, so there haven't been too many FAQ's to -date, but hopefully this document will pre-empt (some|most) of them!! -The ports system is constantly changing, but hopefully this document -will be kept reasonably up to date (and you never know, it might even -make sense!). - - - Gary Palmer - & jkh - -1) What is a port? - - Unfortunately, there are more variations of UN*X than most people -know of, and hence not all software for UN*X available on the Internet -will work on all versions of UN*X (in fact, I can guarantee it!). -Hence, some software needs modifications to work under some UN*Xs. The -process of making those modifications is known as ``porting'' and the -result known as a ``port'' (not to be confused with the sockets on the -back of your computer!). - - -2) What is the FreeBSD Ports Collection? - - People who (allegedly) know what they are doing have automated the -process of ``porting'' software to FreeBSD, and the result is the -Ports Collection. The general idea is that a combination of various -programming tools available in the base FreeBSD installation will -allow you to fetch the port from a FreeBSD mirror site, type ``make'' -and get the fully working program. - - The ports collection itself normally doesn't have any of the -original source code necessary for the compilation in the tree, just -those shell scripts, Makefiles and source code ``diffs'' that are -necessary to compile the program under FreeBSD. This is meant to keep -the entire system down to a manageable size, and the current system -has over 100 ports in the master source tree, and yet a compressed tar -file of that tree is about 2 megabytes (all the source code needed is -over 100Mb's!). - - -3) How does the system compile with no source code? - - A ports' Makefile automatically looks in a central location on -your system (usually /usr/ports/distfiles, though this value can be -customized) for the associated set of original distribution files that -have been ``ported''. These are generally provided at various places -on the Internet, though if you have a CDROM distribution of FreeBSD -then you've already got them available on your CD for ease of use. -See section 3.1 if you have such a CD distribution, otherwise skip to -section 3.2. - -3.1 Compiling ports from CD - - Type something profound here. - -3.2 Compiling ports using an Internet connection - - The ports collection can also use an auto-fetch system to keep -your ports collection source tree up to date, updating the central -``distfiles'' version for you the next time you compile the port. - - Of course, this always assumes you have a permanent network link, -or don't mind heavy usage of your telephone. If you don't want heavy -network usage when you compile your ports tree, you can pre-fetch the -necessary tarballs beforehand and put them into /usr/ports/distfiles -(or wherever DISTDIR points) by hand. A good way to see what files a -port is going to need is to cd to that port's directory and do a -``make -n fetch'' to see what it does. - - You can also chose to get the source files either from the master -FTP site as defined in the relevant Makefile (in the MASTER_SITES -line), or some FreeBSD mirror site also carrying a set of distfiles, -as does the master FTP site on ftp.FreeBSD.org (aka ftp.cdrom.com) in -the directory /pub/FreeBSD/ports/distfiles. Note that the files in -that directory are not guarenteed to be kept up to date - this is a -volunteer project! We can't make any guarantees about the mirror -sites either - they are obviously under independant control and don't -even have to mirror the distfiles directory. - - If you have a non-permanant link, you can fetch all the distfiles by -going to the top of the tree and typing ``make fetch''. - - -4) It doesn't work?! - -Oh. You can do one of four (4) things : - -a) Fix it yourself. Technical details can be found in the GUIDELINES file, - available from URL ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/GUIDELINES - -b) Gripe. This is done by e-mail *ONLY*! The people at Walnut Creek are - in no way responsible for the functionality (or lack thereof) of the - FreeBSD system as a whole, and especially the ports system, which - is mainly contributed by 3rd parties. (If you don't believe me, check - the catalogue, especially the line saying "We cannot offer tech-support - on this product") - - The e-mail address is Ports@FreeBSD.org. Please include details of - the port, where you got both the port source & distfile(s) from, and - what the error was. - - Note: At time of writing, lang/Sather doesn't seem to work on Pentium - machines due to the Intel Curse (aka the Floating Point Division Bug). - Please don't tell us about this - gripe to Intel instead - it's their - bug! - -c) Forget it. This is the easiest for most - very few of the programs in - ports can be classed as `essential'! - -d) Grab the pre-compiled package from a ftp server. The ``master'' package - collection is in: - ftp://ftp.FreeBSD.org/pub/FreeBSD/packages/ - - though check your local mirror first, please! - - These are more likely to work (on the whole) than trying to compile from - source, and a lot faster! - - -5) I've ported a program and I want to make a port out of it. What now? - - See the file GUIDELINES, in: - ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/GUIDELINES - - This contains details of the procedure and structure involved. - - -6) I've got a good port, what now? - - Upload the fixed version to freefall.cdrom.com /pub/incoming or -ftp.FreeBSD.org /pub/FreeBSD/incoming and send e-mail to -ports@FreeBSD.org with the filename and details. Someone on the -all-volunteer `ports committee' will (hopefully) look it over and -commit it to the ports collection if they like the looks of it. - - -7) Things go funny during the fetch stage of compilation! - - We know. Please don't blame us. There is a program called `ncftp' -which is used instead of the normal ftp as it can do so-called -``background'' or ``batch'' transfers, ideal for this situation. -Unfortunately it can do strange things, and has crashed at least one -machine (during circumstances stranger than most, I'll admit, but it -was still responsible). Hopefully a future release of ncftp will fix -these problems (it is not maintained by the main FreeBSD team, but a -third party, who is I believe aware of its shortcomings) - - -8) I want to leave the compile going overnight, but some ports don't - like this. - - There is a way around this. Before starting the compilation, type: - setenv BATCH yes # (if you use csh/tcsh) or - BATCH=yes # (for sh/bash) - - This should miss out ports which need user interaction. Unfortunately, -ncftp doesn't know about this trick, and can often screw up and ask -stupid questions in unattended batch mode. See (7). - - To compile those ports left out by doing the above, using a -different login shell (or unsetting the above BATCH variable), set the -INTERACTIVE variable instead (you can use the same statements as above -except replace ``BATCH'' with ``INTERACTIVE'') and re-run make. This -should now compile only those ports which will definitely ask for user -interaction. - - -9) The ports collection is weak. What can I do to help? - - First read the bsd.port.mk file (which may be found in -/usr/share/mk/) and the associated bsd.port.subdir.mk file. A lot of -the weirdness can be explained properly in there (most of the current -weirdness is due to the lack of assumptions about anything, which is -necessary due to the generic nature of these files). Also check that -you have an up-to-date copy, as the file can change from minute to -minute. A reasonably up-to-date copy can be found in: - - ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/mk/bsd.port* - - If you find that you still need to go in there and alter things, -by all means do so, and then send the diffs to ports@FreeBSD.org if -you'd like them to be a part of the default distribution. Please also -remember that any changes must respect backwards-compatability with -any and all older Makefiles, unless you want a real nightmare of -/usr/ports munging ahead of you! Large scale changes will generally -not be warmly welcomed unless all the existing makefiles work without -alteration. Sorry! - - -10) This FAQ is weak. What can I do? - - Send changes to ports@FreeBSD.org. Changes are most welcome! -This FAQ is also very green and should be considered no more than -a `good start' for now. Authors? You can come out of hiding any -time now! :-) - - -11) How do I get more information on all the ports? - - One good method is to cd to the top of the ports tree (say /usr/ports) -and type something like: - - make describe | sed -e '/===/D' -e 's;/usr/ports/;;' | expand -40 - -The ``make describe'' will try to extract the one-line description from -each port, and the ``sed'' will delete the extraneous output. ``expand'' -just makes it a little more readable (sort of - you may want to season -the output of this more to taste). - - -12) I've heard of a new checksum system. What is this for? - - For various reasons, when using FTP over the Internet to obtain the -source code, you may not always end up with the same copy of the code -that the origional porter worked from, and this can lead to problems. -So a simple checksumming system has been employed to try and highlight -problems in this area. - - To check the entire system, go to the top of the ports tree -(defaults to /usr/ports) and type - - make checksum - -This will give a report on the validity of the files you have FTP'd. If some -are missing, the system will attempt to retrieve them before running the -checksum routine. The same technique can be applied to a single port. - - The system will complain if there is no pre-computed checksum available -for that port. Not all ports currently have checksums, but this should be -cured soon. - - Some older versions of the system don't recognise the ``checksum'' -target. In that case, try the command - - make check-md5 - -(``check-md5'' was the pre-cursor to the ``checksum'' target). If neither -work, get the latest copies of bsd.port.mk and bsd.port.subdir.mk from - - ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/mk/bsd.port* - -and install them in /usr/share/mk. This will get you the latest version -of the ports system. diff --git a/share/FAQ/Text/ppp.FAQ b/share/FAQ/Text/ppp.FAQ deleted file mode 100644 index 46cc8bcf248c..000000000000 --- a/share/FAQ/Text/ppp.FAQ +++ /dev/null @@ -1,369 +0,0 @@ - Info about setting up pppd daemon on FreeBSD-2.0 - -$Id: ppp.FAQ,v 1.2 1995/01/03 15:54:05 gclarkii Exp $ - -Before you start setting up PPP on your machine make -sure that pppd is located in /usr/sbin and directory /etc/ppp -exists. - -pppd can work in two modes: - -i) as a "client" , i.e. you want to connect your machine to outside -world via PPP serial connection or modem line. - -ii) as a "server" , i.e. your machine is located on the network and -used to connect other computers using PPP. - -In both cases you will need to set up an options file ( /etc/ppp/options -or ~/.ppprc if you have more then one user on your machine that uses -PPP ). - -You also will need some modem/serial software ( preferably kermit ) -so you can dial and establish connection with remote host. - -1) Working as a PPP client - -I used the following options to connect to CISCO terminal server PPP -line. - -----/etc/ppp/options------- -crtscts # enable hardware flow control -modem # modem control line -noipdefault # remote PPP server must supply your IP address. - # if the remote host doesn't send your IP during IPCP - # negotiation , remove this option -passive # wait for LCP packets -domain ppp.foo.com # put your domain name here - -:<remote_ip> # put the IP of remote PPP host here - # it will be used to route packets via PPP link - # if you didn't specified the noipdefault option - # change this line to <local_ip>:<remote_ip> - -defaultroute # put this if you want that PPP server will be your - # default router -------------------------- - -To connect: -i) Dial to the remote host using kermit ( or other modem program ) -enter your user name and password ( or whatever is needed to enable PPP -ont the remote host ) - -ii) Exit kermit. ( without hanging up the line ) - -iii) enter: -/usr/src/usr.sbin/pppd.new/pppd /dev/tty01 19200 -( put the appropriate speed and device name ) - -Now your computer is connected with PPP. If the connection fails for some -reasons you can add the "debug" option to the /etc/ppp/options file -and check messages on the console to track the problem - -Following script will make all 3 stages automatically: ------/etc/ppp/pppup-------- -#!/bin/sh -ps ax |grep pppd |grep -v grep -pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` -if [ "X${pid}" != "X" ] ; then - echo 'killing pppd, PID=' ${pid} - kill ${pid} -fi -ps ax |grep kermit |grep -v grep -pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` -if [ "X${pid}" != "X" ] ; then - echo 'killing kermit, PID=' ${pid} - kill -9 ${pid} -fi - -ifconfig ppp0 down -ifconfig ppp0 delete - -kermit -y /etc/ppp/kermit.dial -pppd /dev/tty01 19200 ------------------------------ - -/etc/ppp/kermit.dial is kermit script that dials and makes all -necessary authorization on the remote host. -( Example of such script is attached to the end of this document ) - -Use the follwing script to disconnect the PPP line: ------/etc/ppp/pppdown-------- -#!/bin/sh -pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` -if [ X${pid} != "X" ] ; then - echo 'killing pppd, PID=' ${pid} - kill -TERM ${pid} -fi - -ps ax |grep kermit |grep -v grep -pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` -if [ "X${pid}" != "X" ] ; then - echo 'killing kermit, PID=' ${pid} - kill -9 ${pid} -fi - -/sbin/ifconfig ppp0 down -/sbin/ifconfig ppp0 delete -kermit -y /etc/ppp/kermit.hup -/etc/ppp/ppptest ------------------------------- - -Check if PPP is still running: - ------/etc/ppp/ppptest--------- -#!/bin/sh -pid=`ps ax| grep pppd |grep -v grep|awk '{print $1;}'` -if [ X${pid} != "X" ] ; then - echo 'pppd running: PID=' ${pid-NONE} -else - echo 'No pppd running.' -fi -set -x -netstat -n -I ppp0 -ifconfig ppp0 ------------------------------ - -Hangs up modem line: - ------/etc/ppp/kermit.hup----- -set line /dev/tty01 ; put your modem device here -set speed 19200 -set file type binary -set file names literal -set win 8 -set rec pack 1024 -set send pack 1024 -set block 3 -set term bytesize 8 -set command bytesize 8 -set flow none - -pau 1 -out +++ -inp 5 OK -out ATH0\13 -echo \13 -exit ----------------------------- - -2) Working as a PPP server - -------/etc/ppp/options------ -crtscts # Hardware flow control -netmask 255.255.255.0 # netmask ( not required ) -192.114.208.20:192.114.208.165 # ip's of local and remote hosts - # local ip must be different from one - # you assigned to the ethernet ( or other ) - # interface on your machine. - # remote IP is ip address that will be - # assigned to the remote machine -domain ppp.foo.com # your domain -passive # wait for LCP -modem # modem line ----------------------------- - -Following script will enable ppp server on your machine - ------/etc/ppp/pppserv------- -#!/bin/sh -ps ax |grep pppd |grep -v grep -pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` -if [ "X${pid}" != "X" ] ; then - echo 'killing pppd, PID=' ${pid} - kill ${pid} -fi -ps ax |grep kermit |grep -v grep -pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` -if [ "X${pid}" != "X" ] ; then - echo 'killing kermit, PID=' ${pid} - kill -9 ${pid} -fi - -# reset ppp interface -ifconfig ppp0 down -ifconfig ppp0 delete - -# enable autoanswer mode -kermit -y /etc/ppp/kermit.ans - -# run ppp -pppd /dev/tty01 19200 ----------------------------- - -Use this script to stop ppp server: - ------/etc/ppp/pppservdown--- -#!/bin/sh -ps ax |grep pppd |grep -v grep -pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` -if [ "X${pid}" != "X" ] ; then - echo 'killing pppd, PID=' ${pid} - kill ${pid} -fi -ps ax |grep kermit |grep -v grep -pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` -if [ "X${pid}" != "X" ] ; then - echo 'killing kermit, PID=' ${pid} - kill -9 ${pid} -fi -ifconfig ppp0 down -ifconfig ppp0 delete - -kermit -y /etc/ppp/kermit.noans ----------------------------- - -Following kermit script will enable/disable autoanswer mode -on your modem: - ------/etc/ppp/kermit.ans---- -set line /dev/tty01 -set speed 19200 -set file type binary -set file names literal -set win 8 -set rec pack 1024 -set send pack 1024 -set block 3 -set term bytesize 8 -set command bytesize 8 -set flow none - -pau 1 -out +++ -inp 5 OK -out ATH0\13 -inp 5 OK -echo \13 -out ATS0=1\13 ; change this to out ATS0=0\13 if you want to disable - ; autoanswer mod -inp 5 OK -echo \13 -exit ------------------------------ - -This script is used for dialing and authorizing on remote host. -You will need to customize it for your needs. -Put your login and password in this script , also you'll need -to change input statement depending on responces from your modem -and remote host. - ------/etc/ppp/kermit.dial---- - -; -; put the com line attached to the modem here: -; -set line /dev/tty01 -; -; put the modem speed here: -; -set speed 19200 -set file type binary ; full 8 bit file xfer -set file names literal -set win 8 -set rec pack 1024 -set send pack 1024 -set block 3 -set term bytesize 8 -set command bytesize 8 -set flow none -set modem hayes -set dial hangup off -set carrier auto ; Then SET CARRIER if necessary, -set dial display on ; Then SET DIAL if necessary, -set input echo on -set input timeout proceed -set input case ignore -def \%x 0 ; login prompt counter -goto slhup - -:slcmd ; put the modem in command mode -echo Put the modem in command mode. -clear ; Clear unread characters from input buffer -pause 1 -output +++ ; hayes escape sequence -input 1 OK\13\10 ; wait for OK -if success goto slhup -output \13 -pause 1 -output at\13 -input 1 OK\13\10 -if fail goto slcmd ; if modem doesn't answer OK, try again - -:slhup ; hang up the phone -clear ; Clear unread characters from input buffer -pause 1 -echo Hanging up the phone. -output ath0\13 ; hayes command for on hook -input 2 OK\13\10 -if fail goto slcmd ; if no OK answer, put modem in command mode - -:sldial ; dial the number -pause 1 -echo Dialing. -output atdt9,550311\13\10 ; put phone number here -assign \%x 0 ; zero the time counter - -:look -clear ; Clear unread characters from input buffer -increment \%x ; Count the seconds -input 1 {CONNECT } -if success goto sllogin -reinput 1 {NO CARRIER\13\10} -if success goto sldial -reinput 1 {NO DIALTONE\13\10} -if success goto slnodial -reinput 1 {\255} -if success goto slhup -reinput 1 {\127} -if success goto slhup -if < \%x 60 goto look -else goto slhup - -:sllogin ; login -assign \%x 0 ; zero the time counter -pause 1 -echo Looking for login prompt. - -:slloop -increment \%x ; Count the seconds -clear ; Clear unread characters from input buffer -output \13 -; -; put your expected login prompt here: -; -input 1 {Username: } -if success goto sluid -reinput 1 {\255} -if success goto slhup -reinput 1 {\127} -if success goto slhup -if < \%x 10 goto slloop ; try 10 times to get a login prompt -else goto slhup ; hang up and start again if 10 failures - -:sluid -; -; put your userid here: -; -output ppp-login\13 -input 1 {Password: } -; -; put your password here: -; -output ppp-password\13 -input 1 {Entering SLIP mode.} -echo -quit - -:slnodial -echo \7No dialtone. Check the telephone line!\7 -exit 1 - -; local variables: -; mode: csh -; comment-start: "; " -; comment-start-skip: "; " -; end: ------------------------- - -################################################################### -Gennady B. Sorokopud ( gena@NetVision.net.il ) 24/10/94 12:00 diff --git a/share/FAQ/Text/slip.FAQ b/share/FAQ/Text/slip.FAQ deleted file mode 100644 index 4baf38c7d50f..000000000000 --- a/share/FAQ/Text/slip.FAQ +++ /dev/null @@ -1,192 +0,0 @@ -*********************************************************************** -*** How to Set Up SLIP on FreeBSD *** -*********************************************************************** - -$Id: slip.FAQ,v 1.2 1995/01/03 15:54:06 gclarkii Exp $ - -Updated for 1.1.5(.1) support by Satoshi Asami, 8/6/94. - -The following is I (asami) set up my FreeBSD machine for SLIP on a -static host network. For dynamic hostname assignments (i.e., your -address changes each time you dial up), you probably need to do -something much fancier. - -This is just "what I did, and it worked for me". I'm sharing this -just for your reference, I'm no expert in SLIP nor networking so your -mileage may vary. - -Note: for 1.1 systems (not 1.1.5), you need to use /dev/tty01 instead -of /dev/cua01. substitute all the occurences of "cua" in this document -with "tty". - -Note: the default 1.1.5(.1) system only comes with cua/ttyd pairs for -the last two ports (2 and 3), so if your modem is at sio0/sio1 -(COM1/COM2), you need to make the devices. Try "cd /dev; sh MAKEDEV -cua01" to make the new special files for sio1 (ditto for sio0). This -will delete tty01, but you shouldn't need it anymore...or you can make -a symbolic link /dev/tty01 -> ttyd1 if you don't want to hunt down all -occurences of tty01 in your setup files. - -I actually have a symbolic link /dev/modem -> cua01 (and /dev/mouse -> -ttyd0). I use only the modem/mouse names in my configuration files. -This helped a lot when I switched from 1.1 to 1.1.5.1 (tty01 => cua01) -and when I had to move my modem temporarily to sio2 to enable the -RS-232C port on the serial card. It can become quite cumbersome when -you need to fix a bunch of files in /etc and .kermrc's all over the -system! - -First, make sure you have - -pseudo-device sl 2 - -in your kernel's config file. It is included in the GENERIC, GENERICAH -and GENERICBT kernels, so this won't be a problem unless you deleted it. - -Things you have to do only once: - -(1) Add your home machine, the gateway and nameservers to your - /etc/hosts file. Mine looks like this: - -127.0.0.1 localhost loghost -136.152.64.181 silvia.HIP.Berkeley.EDU silvia.HIP silvia - -136.152.64.1 inr-3.Berkeley.EDU inr-3 slip-gateway -128.32.136.9 ns1.Berkeley.edu ns1 -128.32.136.12 ns2.Berkeley.edu ns2 - - By the way, silvia is the name of the car that I had when I was - back in Japan (it's called 2?0SX here in U.S.). - -(2) Make sure you have "hosts" before "bind" in your /etc/host.conf. - Otherwise, funny things may happen. - -(3) Edit the /etc/netstart and add this to the end of the file: - -# set up slip -gateway=slip-gateway -ifconfig sl0 inet $hostname $gateway netmask 0xffffff00 -route add default $gateway - - Note that because of the "slip-gateway" entry in /etc/hosts, there - is no local dependency in the netstart file. Also, you might want - to un-comment the "route add $hostname localhost" line. - -(3') Make a file /etc/resolv.conf which contains: - -domain HIP.Berkeley.EDU -nameserver 128.32.136.9 -nameserver 128.32.136.12 - - As you can see, these set up the nameserver hosts. Of course, the - actual addresses depend on your environment. - -(4) Set the password for root and toor (and any other accounts that - doesn't have a password). Use passwd, don't edit the passwd or - passwd.master files! - -(5) Edit /etc/myname and reboot the machine. - -How to set up the connection: - -(6) Dial up, type "slip" at the prompt, enter your machine name and - password. The things you need to enter depends on your - environment. I use kermit, with a script like this: - -# kermit setup -set modem hayes -set line /dev/cua01 -set speed 57600 -set parity none -set flow rts/cts -set terminal bytesize 8 -set file type binary -# The next macro will dial up and login -define slip dial 643-9600, input 10 =>, if failure stop, - -output slip\x0d, input 10 Username:, if failure stop, - -output silvia\x0d, input 10 Password:, if failure stop, - -output ***\x0d, echo \x0aCONNECTED\x0a - - (of course, you have to change the hostname and password to fit - yours). Then you can just type "slip" from the kermit prompt to - get connected. - - Note: leaving your password in plain text anywhere in the - filesystem is generally a BAD idea. Do it at your own risk. I'm - just too lazy. - - Note: If you have an 1.1 machine, and kermit doesn't give you a - prompt, try "stty -f /dev/tty01 clocal". I put this in - /etc/rc.local so that it works the first time I boot the machine. - This doesn't apply to 1.1.5(.1) systems, as cua0? are already - configured for dialouts. - -(7) Leave the kermit there (you can suspend it by "z") and as root, - type - -slattach -h -c -s 57600 /dev/cua01 - - if you are able to "ping" hosts on campus, you are connected! - - If it doesn't work, you might want to try "-a" instead of "-c". - -(8) Happy slipping! - -How to shutdown the connection: - -(9) Type "ps gx" (as root) to find out the PID of slattach, and use - "kill -INT" to kill it. - - Then go back to kermit ("fg" if you suspended it) and exit from it - ("q"). - - The slattach man page says you have to use "ifconfig sl0 down" to - mark the interface down, but this doesn't seem to make any - difference for me. ("ifconfig sl0" reports the same thing.) - - Some times, your modem might refuse to drop the carrier (mine - often does). In that case, simply start kermit and quit it again. - It usually goes out on the second try. - - When you want to connect again, go back to (6). You may have to - watch out for clocal mode. If "stty -f /dev/tty01" doesn't tell - you it's clocal, you need to re-set it before kermitting. Again, - this is only for 1.1 machines. - -TROUBLESHOOTING: - -If it doesn't work, feel free to ask me. The things that people -tripped over so far: - -* Not using "-c" or "-a" in slattach (I have no idea why this can be - fatal, but adding this flag solved the problem for at least one - person) - -* Using "s10" instead of "sl0" (might be hard to see the difference on - some fonts :) - -Try "ifconfig sl0" to see your interface status. I get: - -silvia# ifconfig sl0 -sl0: flags=10<POINTOPOINT> - inet 136.152.64.181 --> 136.152.64.1 netmask ffffff00 - -Also, "netstat -r" will give the routing table, in case you get the -"no route to host" messages from ping. Mine looks like: - -silvia# netstat -r -Routing tables -Destination Gateway Flags Refs Use IfaceMTU Rtt -Netmasks: -(root node) -(root node) - -Route Tree for Protocol Family inet: -(root node) => -default inr-3.Berkeley.EDU UG 8 224515 sl0 - - -localhost.Berkel localhost.Berkeley UH 5 42127 lo0 - 0.438 -inr-3.Berkeley.E silvia.HIP.Berkele UH 1 0 sl0 - - -silvia.HIP.Berke localhost.Berkeley UGH 34 47641234 lo0 - 0.438 -(root node) - -(this is after transferring a bunch of files, your numbers should be -smaller). diff --git a/share/FAQ/Text/slip_server.FAQ b/share/FAQ/Text/slip_server.FAQ deleted file mode 100644 index 99b50a217e9d..000000000000 --- a/share/FAQ/Text/slip_server.FAQ +++ /dev/null @@ -1,433 +0,0 @@ - Slip Server - FAQ - For - FreeBSD - -$Id: slip_server.FAQ,v 1.2 1994/12/16 04:01:16 gclarkii Exp $ - -Help for setting up SLIP Server services on a FreeBSD system ------------------------------------------------------------- - -Written by Guy Helmer (ghelmer@alpha.dsu.edu) -Last Updated December 13, 1994 - -This document provides suggestions for setting up SLIP Server services -on a FreeBSD system, which typically means configuring your system to -automatically startup connections upon login for remote SLIP clients. -I've written this document based on my own experience; however, as -your system and needs may be different, this document may not answer -all of your questions, and I cannot be responsible if you damage your -system or lose data due to attempting to follow the suggestions here. - -I have only setup SLIP Server services on a FreeBSD 1.1 system, so if -you are running a different version (such as FreeBSD 2.0), your system -may be different. I've decided to write this document since I've -recently been asked for the umpteenth time how to setup a FreeBSD -machine as a SLIP server :-) - - -1. Prerequisites ----------------- - -This document is very technical in nature, so background knowledge is -required. I must assume that you are familiar with the TCP/IP network -protocol, and in particular, network and node addressing, network -address masks, subnetting, routing, and routing protocols, such as -RIP. Configuring SLIP services on a dial-up server requires a -knowledge of these concepts, and if you are not familiar with them, -please read a copy of either Craig Hunt's "TCP/IP Network -Administration" published by O'Reilly & Associates, Inc. (ISBN Number -0-937175-82-X), or Douglas Comer's book on the TCP/IP protocol. - -I will assume that you have already setup your modem(s) and configured -the appropriate system files to allow logins through your modems (see -the manual pages for sio(4) for information on the serial port device -driver and ttys(5), gettytab(5), getty(8), & init(8) for information -relevant to configuring the system to accept logins on modems, and -perhaps stty(1) for information on setting serial port parameters -[such as "clocal" for directly-connected serial interfaces]). - -2. Quick Overview ------------------ - -In its typical configuration, using FreeBSD as a SLIP server works as -follows: a SLIP user dials up your FreeBSD SLIP Server system and logs -in with a special SLIP login ID that uses "/usr/sbin/sliplogin" as the -special user's shell. The "sliplogin" program browses the file -"/etc/slip.hosts" to find a matching line for the special user, and if -it finds a match, connects the serial line to an available SLIP -interface and then runs /etc/slip.login to configure the SLIP -interface. - -2.1 An Example of a SLIP Server Login -------------------------------------- - -For example, if my SLIP user ID were "Shelmerg", that user's entry in -/etc/master.passwd would look something like this (except it would be -all on one line): - -Shelmerg:password:1964:89::0:0:Guy Helmer - SLIP: - /usr/users/Shelmerg:/usr/sbin/sliplogin - -and, when I log in with that user ID, "sliplogin" will search -/etc/slip.hosts for a line that had a matching user ID; on my system, -I may have a line in /etc/slip.hosts that reads: - -Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp - -sliplogin will find that matching line, hook the serial line I'm on -into the next available SLIP interface, and then execute -/etc/slip.login like this: - -/etc/slip.login 0 19200 Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp - -If all goes well, /etc/slip.login will issue an "ifconfig" for the -SLIP interface to which sliplogin attached itself (slip interface 0, -in the above example, which was the first parameter in the list given -to slip.login) to set the local IP address (dc-slip), remote IP -address (sl-helmer), network mask for the SLIP interface (0xfffffc00), -and any additional flags (autocomp). If something goes wrong, -sliplogin usually logs good informational messages via the daemon -syslog facility, which usually goes into /var/log/messages (see the -manual pages for syslogd(8) and syslog.conf(5), and perhaps check -/etc/syslog.conf to see to which files syslogd is logging). - -OK, enough of the examples -- let's dive into setting up the system. - -3. Kernel Configuration ------------------------ - -FreeBSD's default kernels usually come with two SLIP interfaces -defined (sl0 and sl1); you can use "netstat -i" to see whether these -interfaces are defined in your kernel. - -Sample output from "netstat -i": -Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll -ed0 1500 <Link>0.0.c0.2c.5f.4a 291311 0 174209 0 133 -ed0 1500 138.247.224 ivory 291311 0 174209 0 133 -lo0 65535 <Link> 79 0 79 0 0 -lo0 65535 loop localhost 79 0 79 0 0 -sl0* 296 <Link> 0 0 0 0 0 -sl1* 296 <Link> 0 0 0 0 0 - -The sl0 and sl1 interfaces shown in "netstat -i"'s output indicate -that there are two SLIP interfaces built into the kernel. (The -asterisks after the "sl0" and "sl1" indicate that the interfaces are -"down".) - -However, FreeBSD's default kernels do not come configured to forward -packets (ie, your FreeBSD machine will not act as a router) due to -Internet RFC requirements for Internet hosts (see RFC's 1009 -[Requirements for Internet Gateways], 1122 [Requirements for Internet -Hosts -- Communication Layers], and perhaps 1127 [A Perspective on the -Host Requirements RFCs]), so if you want your FreeBSD SLIP Server to -act as a router, you'll have to add the line "options GATEWAY" to your -machine's kernel configuration file and re-compile the kernel anyway. -(Trivia: "Gateways" are the Internet's old name for what are now -usually called "routers".) - -Please see the BSD System Manager's Manual chapter on "Building -Berkeley Kernels with Config" [the source for which is in -/usr/src/share/doc/smm] and the "FreeBSD Configuration Options" [in -/sys/doc/options.doc] for more information on configuring and building -kernels. You may have to unpack the kernel source distribution if -haven't installed the system sources already (srcdist/srcsys.?? in -FreeBSD 1.1, srcdist/sys.?? in FreeBSD 1.1.5.1, or the entire source -distribution in FreeBSD 2.0-RELEASE) to be able to configure and build -kernels. - -You'll notice that near the end of the default kernel configuration -file (/sys/i386/conf/GENERICAH) is a line that reads: - -pseudo-device sl 2 - -which is the line that defines the number of SLIP devices available in -the kernel; the number at the end of the line is the maximum number of -SLIP connections that may be operating simultaneously. - -See the "Building Berkeley Kernels with Config" and the manual page -for config(8) to see how to configure and build kernels. - -4. Sliplogin Configuration --------------------------- - -As mentioned earlier, there are three files in the /etc directory that -are part of the configuration for /usr/sbin/sliplogin (see -sliplogin(8) for the actual manual page for sliplogin): slip.hosts, -which lists the SLIP users & their associated IP addresses; -slip.login, which usually just configures the SLIP interface; and -slip.logout, which undoes slip.login's effects when the serial -connection is terminated. - -4.1 slip.hosts Configuration & Local and Remote Address Selection ------------------------------------------------------------------ - -/etc/slip.hosts contains lines which have at least four items listed: -a SLIP user's login ID, the local address (local to the SLIP server) -of the SLIP link, the remote address of the SLIP link, and the network -mask. The local and remote addresses may be host names (given in -/etc/hosts or by the domain name service, depending on your -specifications in /etc/host.conf), and I believe the network mask may -be a name that can be resolved by a lookup into /etc/networks. On one -of my systems, /etc/slip.hosts looks like this: - ------ begin /etc/slip.hosts ----- -# -# login local-addr remote-addr mask opt1 opt2 -# (normal,compress,noicmp) -# -Shelmerg dc-slip sl-helmerg 0xfffffc00 autocomp ------ end /etc/slip.hosts ------ - -At the end of the line is one or more of the options: - - "normal" - no header compression - "compress" - compress headers - "autocomp" - compress headers if the remote end allows it - "noicmp" - disable ICMP packets (so any "ping" packets won't use up - any of your bandwidth) - -Your choice of local and remote addresses for your SLIP links depends -on whether you are going to dedicate a TCP/IP subnet or if you are -going to use "proxy ARP" on your SLIP server (it's not "true" proxy -ARP, but that is the terminology that I will use in this document to -describe it). If you're not sure which method to select or how to -assign IP addresses, please refer to the TCP/IP books referenced in -the "Prerequisites" section and/or consult your IP network manager. - -If you are going to use a separate subnet for your SLIP clients, you -will need to allocate the subnet number out of your assigned IP -network number and assign each of your SLIP client's IP numbers out of -that subnet; then you will probably either need to configure a static -route to the SLIP subnet via your SLIP server on your nearest IP -router, or install "gated" on your FreeBSD SLIP server and configure -it to talk the appropriate routing protocols to your other routers to -inform them about your SLIP server's route to the SLIP subnet. - -Otherwise, if you will use the "proxy ARP" method, you will need to -assign your SLIP client's IP addresses out of your SLIP server's -Ethernet subnet, and you'll also need to adjust your /etc/slip.login -and /etc/slip.logout scripts to use arp(8) to manage the proxy-ARP -entries in the SLIP server's ARP table. - -4.2 slip.login Configuration ----------------------------- - -The typical /etc/slip.login file looks like this: - ------ begin /etc/slip.login ----- -#!/bin/sh - -# -# @(#)slip.login 5.1 (Berkeley) 7/1/90 - -# -# generic login file for a slip line. sliplogin invokes this with -# the parameters: -# 1 2 3 4 5 6 7-n -# slipunit ttyspeed loginname local-addr remote-addr mask opt-args -# -/sbin/ifconfig sl$1 inet $4 $5 netmask $6 ------ end /etc/slip.login ----- - -This slip.login file merely ifconfig's the appropriate SLIP interface -with the local and remote addresses and network mask of the SLIP -interface. - -If you have decided to use the "proxy ARP" method (instead of using a -separate subnet for your SLIP clients), your /etc/slip.login file will -need to look something like this: - ------ begin /etc/slip.login for "proxy ARP" ----- -#!/bin/sh - -# -# @(#)slip.login 5.1 (Berkeley) 7/1/90 - -# -# generic login file for a slip line. sliplogin invokes this with -# the parameters: -# 1 2 3 4 5 6 7-n -# slipunit ttyspeed loginname local-addr remote-addr mask opt-args -# -/sbin/ifconfig sl$1 inet $4 $5 netmask $6 -# Answer ARP requests for the SLIP client with our Ethernet addr -/usr/sbin/arp -s $5 00:11:22:33:44:55 pub ------ end /etc/slip.login for "proxy ARP" ----- - -The additional line in this slip.login, "arp -s...", creates an ARP -entry in the SLIP server's ARP table which asks the system to give out -the SLIP server's Ethernet MAC address whenever a another system or -router on the Ethernet asks to speak to the SLIP client's IP address. - -When using the example above, be sure to replace the Ethernet MAC -address (00:11:22:33:44:55) with the MAC address of your system's -Ethernet card, or your "proxy ARP" will definitely not work! You can -discover your SLIP server's Ethernet MAC address by looking at the -results of running "netstat -i"; the second line of the output should -look something like: - -ed0 1500 <Link>0.2.c1.28.5f.4a 191923 0 129457 0 116 - ^^^^^^^^^^^^^^^ - -which indicates that this particular system's Ethernet MAC address is -"00:02:c1:28:5f:4a" -- the periods in the Ethernet MAC address given -by "netstat -i" must be changed to colons and leading zeros should be -added to each single-digit hexadecimal number to convert the address -into the form that arp(8) desires; see the manual page on arp(8) for -complete information on usage. - -Note that when you create /etc/slip.login and /etc/slip.logout, the -"execute" bit ("chmod 755 /etc/slip.login /etc/slip.logout") must be -set, or sliplogin will be unable to execute it. - -4.3 slip.logout Configuration ------------------------------ - -"/etc/slip.logout" isn't strictly needed, but if you decide to create -it, this is an example of a basic slip.logout script: - ------ begin /etc/slip.logout ----- -#!/bin/sh - -# -# slip.logout - -# -# logout file for a slip line. sliplogin invokes this with -# the parameters: -# 1 2 3 4 5 6 7-n -# slipunit ttyspeed loginname local-addr remote-addr mask opt-args -# -/sbin/ifconfig sl$1 down ------ end /etc/slip.logout ----- - -If you are using "proxy ARP", you'll want to have /etc/slip.logout -remove the ARP entry for the SLIP client: - ------ begin /etc/slip.logout for "proxy ARP" ----- -#!/bin/sh - -# -# @(#)slip.logout - -# -# logout file for a slip line. sliplogin invokes this with -# the parameters: -# 1 2 3 4 5 6 7-n -# slipunit ttyspeed loginname local-addr remote-addr mask opt-args -# -/sbin/ifconfig sl$1 down -# Quit answering ARP requests for the SLIP client -/usr/sbin/arp -d $5 ------ end /etc/slip.logout for "proxy ARP" ----- - -The "arp -d $5" removes the ARP entry that the "proxy ARP" slip.login -added when the SLIP client logged in. - -It bears repeating: make sure /etc/slip.logout has the execute bit set -for after you create it (e.g., "chmod 755 /etc/slip.logout"). - -5. Routing Considerations -------------------------- - -If you are not using the "proxy ARP" method for routing packets -between your SLIP clients and the rest of your network (and perhaps -the Internet), you will probably either have to add static routes to -your closest default router(s) to route your SLIP client subnet via -your SLIP server, or you will probably need to install and configure -gated on your FreeBSD SLIP server so that it will tell your routers -via appropriate routing protocols about your SLIP subnet. - -5.1 Static Routes ------------------ - -Adding static routes to your nearest default routers can be -troublesome (or impossible, if you don't have authority to do so...). -If you have a multiple-router network in your organization, some -routers, such as Cisco and Proteon, may not only need to be configured -with the static route to the SLIP subnet, but also need to be told -which static routes to tell other routers about, so some expertise and -troubleshooting/tweaking may be necessary to get static-route-based -routing to work... - -5.2 Running gated ------------------ - -An alternative to the headaches of static routes is to install gated -on your FreeBSD SLIP server and configure it to use the appropriate -routing protocols (RIP/OSPF/BGP/EGP) to tell other routers about your -SLIP subnet. gated is available from ftp.gated.cornell.edu in -/pub/gated; I believe the current version as of this writing is -"gated-R3_5Alpha_8.tar.Z", which should include support for FreeBSD -"out-of-the-box". Compile and install it, and then write a -/etc/gated.conf file to configure your gated; here's a sample, similar -to what I use on my FreeBSD SLIP server: - ------ begin sample /etc/gated.conf for gated version 3.5Alpha5 ----- -# -# gated configuration file for dc.dsu.edu; for gated version 3.5alpha5 -# Only broadcast RIP information for xxx.xxx.yy out the ed Ethernet interface -# -# -# tracing options -# -traceoptions "/var/tmp/gated.output" replace size 100k files 2 general ; - -rip yes { - interface sl noripout noripin ; - interface ed ripin ripout version 1 ; - traceoptions route ; -} ; - -# -# Turn on a bunch of tracing info for the interface to the kernel: -kernel { - traceoptions remnants request routes info interface ; -} ; - -# -# Propagate the route to xxx.xxx.yy out the Ethernet interface via RIP -# - -export proto rip interface ed { - proto direct { - xxx.xxx.yy mask 255.255.252.0 metric 1; # SLIP connections - } ; -} ; - -# -# Accept routes from RIP via ed Ethernet interfaces - -import proto rip interface ed { - all ; -} ; - ------ end sample /etc/gated.conf ----- - -The above sample gated.conf file broadcasts routing information -regarding the SLIP subnet "xxx.xxx.yy" via RIP onto the Ethernet; if -you are using a different Ethernet driver than the "ed" driver, you'll -need to change the references to the "ed" interface appropriately. -This sample file also sets up tracing to /var/tmp/gated.output for -debugging gated; you can certainly turn off the tracing options if -gated works OK for you. I've changed my SLIP subnet's address to -"xxx.xxx.yy" throughout the above file; you'll need to change the -"xxx.xxx.yy"'s into the network address of your own SLIP subnet (be -sure to change the net mask in the "proto direct" clause as well). -Complete gated configuration information may be read through the Web -at "http://www.gated.cornell.edu/". - -When you get gated built and installed, and create a configuration -file for it, you'll need to run gated in place of routed on your -FreeBSD system; change the routed/gated startup parameters in -/etc/netstart as appropriate for your system. Please see the manual -page for gated for information on gated's command-line parameters. - -6. Acknowledgements -------------------- - -Thanks to these people for comments and advice regarding this FAQ: - - Wilko Bulte <wilko@yedi.iaf.nl> - Piero Serini <Piero@Strider.Inet.IT> - -<<< END OF SLIP SERVER FAQ >>> - - diff --git a/share/FAQ/Text/submitters.FAQ b/share/FAQ/Text/submitters.FAQ deleted file mode 100644 index 69a79f358c06..000000000000 --- a/share/FAQ/Text/submitters.FAQ +++ /dev/null @@ -1,167 +0,0 @@ --- A submitter's guide to FreeBSD -- - -This guide is intended for those who are moderately familar with FreeBSD -and are now to the point where they have some locally developed -customizations or fixes to the system which they'd like to incorporate -back into the mainstream sources, thus saving the work of having to -re-integrate the changes for each subsequent FreeBSD release. Submitting -something to the FreeBSD project is also an excellent way of getting your -code seriously *tested*! Many people have developed an original concept -far beyond what they might have envisioned at the start just due to the -flood of feedback and ideas generated by the many thousands of users of -FreeBSD. Contributions are also what FreeBSD lives and grows from, -and so your contributions are very important to the continued survival -of this communal effort of ours - we're very glad to see you reading this -documentation! :-) - -Submissions to FreeBSD can generally be classified into four catagories: - -1. Ideas, general suggestions, bug reports. -2. Addition, deletion, renaming or patching of existing sources. -3. Significant contribution of a large body of independant work. -4. Porting of freely available software. - -A submission in *any* of these catagories is highly welcomed as they -are each, in their own way, quite significant to the project. - - -1. An idea, suggestion or fix can be communicated in one of the following ways: - - o An idea or suggestion of general technical interest should be - mailed to <hackers@freebsd.org>. Likewise, people with an interest - in such things (and a tolerance for a HIGH volume of mail!) may - subscribe by sendimg mail to <majordomo@freebsd.org>. See also the - file /usr/share/FAQ/mailing-list.FAQ. - - o An actual bug report should be filed by using the send-pr(1) - command (``man send-pr'' for information). This will prompt - you for various fields to fill in. Simply go to the fields - surrounded by <>'s and fill in your own information in place of - what's suggested there. You should receive confirmation of your - bug report and a tracking number (which you should also reference in - any subsequent correspondence). - - If you do not receive confirmation in a timely fashion (3 days to - a week, depending on your email connection) or are, for some - reason, unable to use the send-pr command, then you may also - file a bug report (or follow-up to one) by sending mail to: - - <bugs@freebsd.org> - - -2. An addition or change to the existing source code is a somewhat trickier - affair and depends a lot on how far out of date you are with the current - state of the core FreeBSD development. There is a special on-going release - of FreeBSD known as "FreeBSD-current" and made available in a variety of - ways (see /usr/share/FAQ/current-policy.FAQ and /usr/share/FAQ/ctm.FAQ) for - the convenience of developers who wish to actively work on the system. - - Working from older sources unfortunately means that your changes may - sometimes be too obsolete to use, or too divergent to allow for easy - re-integration. This can be minimized somewhat by subscribing to the - <announce@freebsd.org> mailing list (among others) where periodic - announcements concerning the current state of the system are made. - If you see a change being proposed for which you have a better solution, - then please, by all means come forward with your contribution and we - will do our very best to evaluate it fairly and perhaps integrate it if - it is indeed a better (or easier :) solution. - - Assuming that you can manage to secure fairly up-to-date sources to base - your changes on, the next step is to produce a set of diffs to send to the - FreeBSD maintainers for evaluation and possible adoption. This is done - with the diff(1) command, with the FreeBSD maintainers preferring to receive - diffs in `context diff' form. See the man page for diff for more details - on producing both context and recursive context diffs - (diff -c <oldfile> <newfile> or diff -c -r <olddir> <newdir>). - - Once you have a set of diffs that are capable of taking a copy of the - original code and bringing it to a state identical to the "new" sources - (you may test this with the patch(1) command - see patch man page), you - should bundle them up in an email message and send it, along with a brief - description of what the diffs are for, to <hackers@freebsd.org>. Someone - will very likely get back in touch with you in 24 hours or less, assuming - of course that your diffs are interesting! :-) - - If your changes don't express themselves well as diffs alone (e.g. you've - perhaps added, deleted or renamed files as well) then you may be better off - bundling any new files, diffs and instructions for deleting/renaming any - others into a tar file and running the `uuencode' program on it before - sending the output of that to <hackers@freebsd.org>. See the man pages - on tar and uuencode for more info on bundling files through the mail this - way. - - If your change is of a potentially sensitive nature, e.g. you're unsure - of copyright issues governing its further distribution, or you're simply - not ready to release it without a tighter review first, then you should - send it to <core@freebsd.org> rather than <hackers@freebsd.org>. The core - mailing list reaches a much smaller group of people who do much of the - day-to-day work on FreeBSD. Note that this group is also VERY BUSY and so - you should really only mail to them in cases where mailing to hackers - truly is impractical. - - -3. In the case of a significant contribution of a large body work, or the - addition of an important new feature to FreeBSD, it becomes almost always - necessary to either send changes as uuencoded tar files (see above) - or upload them to our ftp site: - ftp://freefall.cdrom.com/pub/FreeBSD/incoming - - Users may log in anonymously and upload their work or download the - work-in-progress files left by others. - - When working with large amounts of code, the touchy subject of copyrights - also invariably comes up. The view of the FreeBSD project towards - acceptable copyrights (for code included in FreeBSD) are: - - 3a. Contributions under the BSD copyright (see the file - /usr/share/examples/etc/bsd-style-copyright for a template) - is greatly preferred due to its "no strings attached" - nature and general attractiveness to commercial enterprises - who might then be inclined to invest something of their own - into FreeBSD. - - 3b. Contributions under the GNU Public License, or "GPL". This is - not quite as popular a solution for us, due to (all religious - issues aside) the amount of extra effort demanded of anyone - using the code for commercial purposes. However, given the - sheer quantity of GPL'd code we currently require (compiler, - assembler, text formatter, etc), it would be silly to pretend - that we couldn't deal with the GPL at all and so we have become - more willing to accept code with either the BSD or the GPL - copyright. Code under the GPL also goes into a different part - of the tree, that being /sys/gnu or /usr/src/gnu. - - 3c. Contributions coming under any other type of copyright must be - carefully reviewed before their inclusion into FreeBSD will even - be considered. Contributions for which particularly restrictive - commercial copyrights apply are generally rejected, though the - authors are always free to make the changes available through - their own channels. - - -4. The porting of freely available software, while perhaps not as gratifying - as developing your own package from scratch, is still a vital part of - FreeBSD's growth and of great usefulness to those who wouldn't otherwise - know where to turn for it. All ported software is organized into a - hierarchy know as ``the ports collection''. This collection enables - a new user to get a complete overview of what's available in a short time, - and with a logical (we hope) framework. The ports collection also saves - considerable space by not actually containing the the majority of the - sources being ported. This can be confusing to the new user and the file - /usr/share/FAQ/ports.FAQ goes some way towards explaing how it all works. - - If you have the ports collection on your machine, the file - /usr/ports/GUIDELINES also helps to explain the process of creating - and contributing a port of your own. For more information on the ports - collection (that wasn't available in the FAQ), you may also send mail to - <ports@freebsd.org>. - - -Whichever way you decide to contribute, we hope you'll find it an enjoyable -process and also realize how valuable your contributions are to the project! -FreeBSD is one of those great projects where the more we all put in, the -more we all get back out of it again, and with enough steady contributions -it begins to aquire a momentum of its own. It is through such momentum -that mountains are moved! :-) - - Jordan diff --git a/share/FAQ/Text/sup.FAQ b/share/FAQ/Text/sup.FAQ deleted file mode 100644 index 681d123c736d..000000000000 --- a/share/FAQ/Text/sup.FAQ +++ /dev/null @@ -1,91 +0,0 @@ - FreeBSD - Sup FAQ - -$Id: sup.FAQ,v 1.1 1995/03/21 20:19:46 jkh Exp $ - - SUP is a network based software update tool developed at CMU. The -purpose of this document is get the beginner up and running with sup. - - First off you will need to pick up the sup binaries. The easiest -way of doing this is to grab the sup.tgz package from: - - ftp://ftp.FreeBSD.ORG:/pub/FreeBSD/packages/sup.tgz - -Install the sup package using pkg_add and add the following line to -your /etc/services file: - - sup 871/tcp #sup - -SUP gets the information it needs to run from a configuration file -called a supfile. This file tells sup what collections it will be updating -and/or installing and where they go. The supfile in this directory will -sup both the source and ports collection - look for the blank line seperating -the two collections; if you don't want ports, you can simply delete all the -ports entries. If you're inside the United States, you may also uncomment -the `secure' collection line to grab the DES code. If you're outside the -U.S., you should NOT sup this code from FreeBSD.ORG as this will -violate U.S. export restrictions. Simply sup everything *but* the secure -collection and then go look on "braae.ru.ac.za", where it's available for -anonymous ftp for those outside the U.S. - -Any other distributions you do not wish to receive can be commented out -with a # at the begining of the distribution line. - -Once this is setup, you're ready to go. To start sup type: - - sup supfile - -If you wish to see what sup is doing "verbosely", give it the -v option, -like so: - - sup -v supfile - -Thats all there is to it! Remember that if you're running current, -which is what you will have if you sup, please join the freebsd-current -mailing list. You should also be sure to read: - - ftp://ftp.FreeBSD.ORG:/pub/FreeBSD/FAQ/current-policy.FAQ - -For important information on just what we can and cannot do for you as -a -current user. - -Gary Clark II / Jordan Hubbard -FreeBSD maintainance persons. - ----- - -Description of FreeBSD SUP distributions: - -base: /usr/src/... misc files at the top of /usr/src -bin: /usr/src/bin system binaries -secure: /usr/src/secure DES Sources. U.S./Canada only! -etc: /usr/src/etc system files -games: /usr/src/games games -gnu: /usr/src/gnu sources under the GNU Public License -include: /usr/src/include include files -sys: /usr/src/sys kernel sources -lib: /usr/src/lib libraries -libexec: /usr/src/libexec more system binaries -share: /usr/src/share various shared resources -sbin: /usr/src/sbin even more system binaries -usrbin: /usr/src/usr.bin user binaries -usrsbin: /usr/src/usr.sbin that's it for the system binaries - -Ports: - -ports-base: /usr/ports/... misc files at the top of /usr/ports -ports-editors: /usr/ports/editors text editors -ports-game: /usr/ports/games games -ports-lang: /usr/ports/lang programming languages -ports-mail: /usr/ports/mail mail software -ports-math: /usr/ports/math math software -ports-net: /usr/ports/net networking software -ports-news: /usr/ports/news USENET news software -ports-print: /usr/ports/print printing software -ports-russian: /usr/ports/russian russian software -ports-shells: /usr/ports/shells various UN*X shells -ports-utils: /usr/ports/utils miscellaneous utilities -ports-x11: /usr/ports/x11 X11 software - - - diff --git a/share/FAQ/Text/systems.FAQ b/share/FAQ/Text/systems.FAQ deleted file mode 100644 index 34c8e71fa6f6..000000000000 --- a/share/FAQ/Text/systems.FAQ +++ /dev/null @@ -1,59 +0,0 @@ - - Systems FAQ - for FreeBSD 2.0 - -This FAQ lists systems (and componets) known to work with FreeBSD 2.0. None -of these lists should be seen as a recomandation for a manufacture. - -$Id: systems.FAQ,v 1.2 1995/01/03 15:54:08 gclarkii Exp $ - - -i386: - - -Motherboard: Magitronics 386DX-40 -CPU: i386DX-40 -Busses: ISA and VLB (VLB not tested) -Ram: 20 Megs -Video: Generic 1MB Tseng 4000 (ISA) -Disks: - 2 - Segate ST1126 (SCSI) - 1 - Seagate ST1480 (SCSI) - 1 - Toshiba MK-234FC-C (IDE) -Controllers: - Generic IDE - Adaptec AH-1542CF - -Motherboard: Magitronics 386SX-40 -CPU: i386SX-40 -Busses: ISA -Ram: 4 Megs -Video: Monochrome -Disks: - 1-Seagate ST1126 (SCSI) -Controllers: - Future Domain 850 -Notes: Slow but useable - -i486: - -Motherboard: Gateway 2000 Handbook 486 HB486DX2-40 -CPU: i486SL DX2/40 -BUS(S): PCMCIA, one type II -Video Card: Monochrome VGA. -Are you running X on this?: no, havn't really tried. -Types of Disks (manufacture and bus): 130Mb builtin. <Areal A130 U> -If you wish to be credited: Poul-Henning Kamp phk@freefall.cdrom.com - -NOTES: -This is a 3 pound portable. Runs perfect. Suspend works great. Has one -serial and one parallel/floppy port, which can drive either a floppy or -a parallel port, but not at the same time. Builtin "EZ" mouse-thinge. -Highly recommended for people on the road. - - -Credits: - FreeBSD Core Team - Gary Clark II - Poul-Henning Kamp - |