Two new sections:
* Kernel configuration, from Jake Hamby <jehamby@lightside.com>
I'd like as many people as possible to give this one a good
check before 2.1 goes out the door.
* Routing, from Coranth Gryphon <gryphon@healer.com>
A bazillion formatting tweaks (only 13 bazillion more to go!)
This commit is contained in:
John Fieber
parent
48861faf4c
commit
f56c1a6397
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=119
17 changed files with 1640 additions and 159 deletions
|
|
@ -1,12 +1,13 @@
|
|||
# $Id: Makefile,v 1.4 1995-10-01 04:43:11 jfieber Exp $
|
||||
# $Id: Makefile,v 1.5 1995-10-07 04:31:10 jfieber Exp $
|
||||
|
||||
SRCS= authors.sgml basics.sgml bibliography.sgml boothelp.sgml
|
||||
SRCS+= booting.sgml contrib.sgml crypt.sgml ctm.sgml current.sgml dialup.sgml
|
||||
SRCS+= diskless.sgml dma.sgml eresources.sgml esdi.sgml glossary.sgml
|
||||
SRCS+= handbook.sgml history.sgml hw.sgml install.sgml kerberos.sgml
|
||||
SRCS+= kerneldebug.sgml memoryuse.sgml mirrors.sgml nfs.sgml nutshell.sgml
|
||||
SRCS+= kernelconfig.sgml kerneldebug.sgml memoryuse.sgml
|
||||
SRCS+= mirrors.sgml nfs.sgml nutshell.sgml
|
||||
SRCS+= porting.sgml ports.sgml ppp.sgml printing.sgml relnotes.sgml
|
||||
SRCS+= scsi.sgml sections.sgml
|
||||
SRCS+= routing.sgml scsi.sgml sections.sgml
|
||||
SRCS+= skey.sgml slipc.sgml slips.sgml submitters.sgml sup.sgml
|
||||
SRCS+= troubleshooting.sgml userppp.sgml
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: authors.sgml,v 1.9 1995-10-01 04:43:12 jfieber Exp $ -->
|
||||
<!-- $Id: authors.sgml,v 1.10 1995-10-07 04:31:13 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!--
|
||||
|
|
@ -39,6 +39,14 @@ and double quotes.
|
|||
<tt><htmlurl url='mailto:gpalmer@FreeBSD.org'
|
||||
name='<gpalmer@FreeBSD.org>'></tt>">
|
||||
|
||||
<!ENTITY a.gryphon "Coranth Gryphon
|
||||
<tt><htmlurl url='mailto:gryphon@healer.com'
|
||||
name='<gryphon@healer.com>'></tt>">
|
||||
|
||||
<!ENTITY a.jehamby "Jake Hamby
|
||||
<tt><htmlurl url='mailto:jehamby@lightside.com'
|
||||
name='<jehamby@lightside.com>'></tt>">
|
||||
|
||||
<!ENTITY a.jfieber "John Fieber
|
||||
<tt><htmlurl url='mailto:jfieber@FreeBSD.org'
|
||||
name='<jfieber@FreeBSD.org>'></tt>">
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
|
||||
This conversion has been made by Ollivier Robert.
|
||||
|
||||
$Id: booting.sgml,v 1.6 1995-09-25 04:53:28 jfieber Exp $
|
||||
$Id: booting.sgml,v 1.7 1995-10-07 04:31:15 jfieber Exp $
|
||||
|
||||
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN">
|
||||
|
|
@ -133,7 +133,7 @@
|
|||
<tt>/rootfs/bin -> /bin</tt><newline>
|
||||
<tt>/rootfs/etc -> /etc</tt><newline>
|
||||
<tt>/rootfs/sbin -> /sbin</tt><newline>
|
||||
...<newline>
|
||||
(etc...)<newline>
|
||||
</itemize>
|
||||
|
||||
Now you run FreeBSD without repartitioning your hard disk...
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: eresources.sgml,v 1.13 1995-10-03 21:38:20 jfieber Exp $ -->
|
||||
<!-- $Id: eresources.sgml,v 1.14 1995-10-07 04:31:17 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<chapt>
|
||||
|
|
@ -21,10 +21,7 @@
|
|||
<sect>
|
||||
<heading>Mailing lists<label id="eresources:mail"></heading>
|
||||
|
||||
<p><em>Contributed by &a.dufalt;.<newline>
|
||||
20 Jun 1995.</em>
|
||||
|
||||
Though many of the FreeBSD development members read USENET, we cannot
|
||||
<p>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.unix.bsd.*
|
||||
groups. By addressing your questions to the appropriate mailing list
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: esdi.sgml,v 1.1 1995-09-25 04:53:30 jfieber Exp $ -->
|
||||
<!-- $Id: esdi.sgml,v 1.2 1995-10-07 04:31:20 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!--
|
||||
|
|
@ -23,7 +23,7 @@
|
|||
|
||||
<sect><heading>ESDI hard disks and FreeBSD<label id="esdi"></heading>
|
||||
|
||||
<p><em>© 1995, &a.wilko;.<newline>24 September 1995.</em>
|
||||
<p><em>Copyright © 1995, &a.wilko;.<newline>24 September 1995.</em>
|
||||
|
||||
ESDI is an acronym that means Enhanced Small Device Interface.
|
||||
It is loosely based on the good old ST506/412 interface originally
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: handbook.sgml,v 1.31 1995-10-01 04:43:12 jfieber Exp $ -->
|
||||
<!-- $Id: handbook.sgml,v 1.32 1995-10-07 04:31:23 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [
|
||||
|
|
@ -24,7 +24,7 @@
|
|||
<author>
|
||||
<name>The FreeBSD Documentation Project</name>
|
||||
</author>
|
||||
<date>September 30, 1995</date>
|
||||
<date>October 6, 1995</date>
|
||||
|
||||
<abstract>Welcome to FreeBSD! This handbook covers the
|
||||
installation and day to day use of <bf>FreeBSD Release
|
||||
|
|
@ -34,7 +34,7 @@ This manual is a <bf>work in progress</bf> and is the
|
|||
work of many individuals. Many sections do not yet exist
|
||||
and some of those that do exist need to be updated. If
|
||||
you are interested in helping with this project, send
|
||||
email to &a.jfieber; or to the FreeBSD Documentation
|
||||
email to the FreeBSD Documentation
|
||||
Project mailing list <tt><htmlurl url="mailto:doc@freebsd.org"
|
||||
name="<doc@freebsd.org>"></tt>.
|
||||
The latest version of this document is always available from
|
||||
|
|
@ -65,15 +65,7 @@ Web server">.
|
|||
|
||||
<part><heading>System Administration</heading>
|
||||
|
||||
<chapt><heading>Reconfiguring the Kernel<label id="kernelconfig"></heading>
|
||||
<p>This section is in progress. Please contact
|
||||
Deborah Bennett <htmlurl url="mailto:deborah@gallifrey.microunity.com"
|
||||
name="<deborah@gallifrey.microunity.com>"> for more information.
|
||||
In the meantime, please refer to
|
||||
Kernel Configuration section of the <url url="../FAQ/freebsd-faq.html"
|
||||
name="FreeBSD FAQ">.
|
||||
<!-- &kernelconfig; -->
|
||||
|
||||
&kernelconfig;
|
||||
<chapt><heading>Users, groups and security</heading>
|
||||
&crypt;
|
||||
&skey;
|
||||
|
|
@ -81,12 +73,6 @@ Web server">.
|
|||
<sect><heading>* Firewalls</heading>
|
||||
|
||||
&printing;
|
||||
<!--
|
||||
<chapt><heading>Printing</heading>
|
||||
<p>This section is in progress. Please contact
|
||||
Sean Kelly <url url="mailto:kelly@fsl.noaa.gov"
|
||||
name="kelley@fsl.noaa.gov"> for more information.
|
||||
-->
|
||||
<chapt><heading>The X-Window System</heading>
|
||||
<p>Pending the completion of this section, please refer to
|
||||
documentation supplied by the <url url="http://www.xfree86.org/"
|
||||
|
|
@ -127,11 +113,13 @@ Web server">.
|
|||
&slips;
|
||||
|
||||
<chapt><heading>Advanced networking</heading>
|
||||
<!--
|
||||
<sect><heading>Gateways and routing</heading>
|
||||
<p>This section is in progress. Please contact
|
||||
Coranth Gryphon <htmlurl url="mailto:gryphon@healer.com"
|
||||
name="<gryphon@healer.com>"> for more information.
|
||||
|
||||
-->
|
||||
&routing;
|
||||
&nfs;
|
||||
&diskless;
|
||||
<sect><heading>* Yellow Pages/NIS</heading>
|
||||
|
|
@ -164,7 +152,7 @@ Web server">.
|
|||
&memoryuse;
|
||||
&dma;
|
||||
&contrib;
|
||||
&glossary;
|
||||
<!-- &glossary; -->
|
||||
|
||||
</book>
|
||||
</linuxdoc>
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: hw.sgml,v 1.7 1995-10-02 15:59:53 wollman Exp $ -->
|
||||
<!-- $Id: hw.sgml,v 1.8 1995-10-07 04:31:26 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!--
|
||||
|
|
@ -54,14 +54,14 @@
|
|||
known work around is to turn the cache
|
||||
off.
|
||||
|
||||
<tag>Saturn-I <em>(ie, 82424ZX at rev 0, 1 or
|
||||
2)</em>:</tag> write back cache coherency
|
||||
<tag>Saturn-I <em>(ie, 82424ZX at rev 0, 1 or 2)</em>:</tag>
|
||||
Write back cache coherency
|
||||
problems. Hardware flaw, only known work around
|
||||
is to set the external cache to write-through
|
||||
mode. Upgrade to Saturn-II.
|
||||
|
||||
<tag>Saturn-II <em>(ie, 82424ZX at rev 3 or
|
||||
4)</em>:</tag> Works fine, but many MB
|
||||
<tag>Saturn-II <em>(ie, 82424ZX at rev 3 or 4)</em>:</tag>
|
||||
Works fine, but many MB
|
||||
manufactures leave out the external dirty bit
|
||||
SRAM needed for write back operation. Work
|
||||
arounds are either run it in write through mode,
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: install.sgml,v 1.12 1995-09-27 00:46:20 jmz Exp $ -->
|
||||
<!-- $Id: install.sgml,v 1.13 1995-10-07 04:31:28 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!--
|
||||
|
|
@ -549,8 +549,9 @@ C> XCOPY /S E:\DISTS C:\FREEBSD\
|
|||
<p>You can do network installations over 3 types of
|
||||
communications links:
|
||||
<descrip>
|
||||
<tag>Serial port</tag> SLIP or PPP <tag>Parallel
|
||||
port</tag> PLIP (laplink cable) <tag>Ethernet</tag> A
|
||||
<tag>Serial port</tag> SLIP or PPP
|
||||
<tag>Parallel port</tag> PLIP (laplink cable)
|
||||
<tag>Ethernet</tag> A
|
||||
standard ethernet controller (includes some PCMCIA).
|
||||
</descrip>
|
||||
|
||||
|
|
|
|||
1206
handbook/kernelconfig.sgml
Normal file
1206
handbook/kernelconfig.sgml
Normal file
File diff suppressed because it is too large
Load diff
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: porting.sgml,v 1.6 1995-10-03 07:11:51 asami Exp $ -->
|
||||
<!-- $Id: porting.sgml,v 1.7 1995-10-07 04:31:35 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>Porting applications<label id="porting"></heading>
|
||||
|
|
@ -120,23 +120,23 @@
|
|||
<p>The minimal <tt>Makefile</tt> would look something like this:
|
||||
|
||||
<tscreen><verb>
|
||||
# New ports collection makefile for: oneko
|
||||
# Version required: 1.1b
|
||||
# Date created: 5 December 1994
|
||||
# Whom: asami
|
||||
#
|
||||
# $Id: porting.sgml,v 1.6 1995-10-03 07:11:51 asami Exp $
|
||||
#
|
||||
|
||||
DISTNAME= oneko-1.1b
|
||||
CATEGORIES+= games
|
||||
MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/
|
||||
|
||||
MAINTAINER= asami@FreeBSD.ORG
|
||||
|
||||
USE_IMAKE= yes
|
||||
|
||||
.include <bsd.port.mk>
|
||||
# New ports collection makefile for: oneko
|
||||
# Version required: 1.1b
|
||||
# Date created: 5 December 1994
|
||||
# Whom: asami
|
||||
#
|
||||
# $Id: porting.sgml,v 1.7 1995-10-07 04:31:35 jfieber Exp $
|
||||
#
|
||||
|
||||
DISTNAME= oneko-1.1b
|
||||
CATEGORIES+= games
|
||||
MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/
|
||||
|
||||
MAINTAINER= asami@FreeBSD.ORG
|
||||
|
||||
USE_IMAKE= yes
|
||||
|
||||
.include <bsd.port.mk>
|
||||
</verb></tscreen>
|
||||
|
||||
<p>See if you can figure it out. Don't worry about the contents
|
||||
|
|
@ -725,11 +725,11 @@ FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2
|
|||
user can set in <tt>/etc/make.conf</tt> to disable man page
|
||||
compression. Here's an example:
|
||||
<tscreen><verb>
|
||||
post-install:
|
||||
strip ${PREFIX}/bin/xdl
|
||||
.if !defined(NOMANCOMPRESS)
|
||||
gzip -9nf ${PREFIX}/man/man1/xdl.1
|
||||
.endif
|
||||
post-install:
|
||||
strip ${PREFIX}/bin/xdl
|
||||
.if !defined(NOMANCOMPRESS)
|
||||
gzip -9nf ${PREFIX}/man/man1/xdl.1
|
||||
.endif
|
||||
</verb></tscreen>
|
||||
|
||||
<p>Use the <tt>file</tt> command on the installed executable
|
||||
|
|
@ -874,75 +874,75 @@ lib/libtcl.so.7.3
|
|||
important information is easy to locate.
|
||||
|
||||
<tscreen><verb>
|
||||
[the header...just to make it easier for us to identify the ports]
|
||||
# New ports collection makefile for: xdvi
|
||||
# Version required: 2.2 [things like "1.5alpha" are fine here too]
|
||||
# Date created: 26 May 1995
|
||||
[this is the person who did the original port to FreeBSD, in particular, the
|
||||
person who wrote this Makefile]
|
||||
# Whom: Satoshi Asami <asami@FreeBSD.ORG>
|
||||
#
|
||||
# $Id: porting.sgml,v 1.6 1995-10-03 07:11:51 asami Exp $
|
||||
[ ^^^^ don't worry about this...it will be automatically filled in by CVS when
|
||||
it is committed to our repository]
|
||||
#
|
||||
|
||||
[section to describe the package itself and main ftp site - DISTNAME
|
||||
is always first, followed by PKGNAME (if necessary), CATEGORIES,
|
||||
KEYWORDs (if necessary) and then MASTER_SITES, and optionally
|
||||
EXTRACT_SUFX or DISTFILES]
|
||||
DISTNAME= xdvi
|
||||
PKGNAME= xdvi-pl18
|
||||
CATEGORIES+= printing
|
||||
[don't forget the trailing slash ("/")!]
|
||||
MASTER_SITES= ftp://crl.dec.com/pub/X11/contrib/applications/
|
||||
[set this if the source is not in the standard ".tar.gz" form]
|
||||
EXTRACT_SUFX= .tar.Z
|
||||
|
||||
[section for distributed patches -- can be empty]
|
||||
PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/
|
||||
PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz
|
||||
|
||||
[maintainer; *mandatory*! This is the person (preferably with commit
|
||||
privileges) who a user can contact for questions and bug reports - this
|
||||
person should be the porter or someone who can forward questions to the
|
||||
original porter reasonably promptly. If you really don't want to have your
|
||||
address here, set it to "ports@FreeBSD.ORG".]
|
||||
MAINTAINER= asami@FreeBSD.ORG
|
||||
|
||||
[dependencies -- can be empty]
|
||||
RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript
|
||||
LIB_DEPENDS= Xpm\\.4\\.:${PORTSDIR}/graphics/xpm
|
||||
|
||||
[this section is for other standard bsd.port.mk variables that don't belong to
|
||||
any of the above]
|
||||
[If it extracts to a directory other than ${DISTNAME}...]
|
||||
WRKSRC= ${WRKDIR}/xdvi-new
|
||||
[If it asks questions during configure, build, install...]
|
||||
IS_INTERACTIVE= yes
|
||||
[If it requires "configure" in the distributed source directory to be run...]
|
||||
HAS_CONFIGURE= yes
|
||||
[If it requires GNU make, not /usr/bin/make, to build...]
|
||||
USE_GMAKE= yes
|
||||
[If it is an X application and requires "xmkmf -a" to be run...]
|
||||
USE_IMAKE= yes
|
||||
[et cetera.]
|
||||
|
||||
[non-standard variables to be used in the rules below]
|
||||
MY_FAVORITE_RESPONSE= "yeah, right"
|
||||
|
||||
[then the special rules, in the order they are called]
|
||||
pre-fetch:
|
||||
i go fetch something, yeah
|
||||
|
||||
post-patch:
|
||||
i need to do something after patch, great
|
||||
|
||||
pre-install:
|
||||
and then some more stuff before installing, wow
|
||||
|
||||
[and then the epilogue]
|
||||
.include <bsd.port.mk>
|
||||
[the header...just to make it easier for us to identify the ports]
|
||||
# New ports collection makefile for: xdvi
|
||||
# Version required: 2.2 [things like "1.5alpha" are fine here too]
|
||||
# Date created: 26 May 1995
|
||||
[this is the person who did the original port to FreeBSD, in particular, the
|
||||
person who wrote this Makefile]
|
||||
# Whom: Satoshi Asami <asami@FreeBSD.ORG>
|
||||
#
|
||||
# $Id: porting.sgml,v 1.7 1995-10-07 04:31:35 jfieber Exp $
|
||||
[ ^^^^ don't worry about this...it will be automatically filled in by CVS when
|
||||
it is committed to our repository]
|
||||
#
|
||||
|
||||
[section to describe the package itself and main ftp site - DISTNAME
|
||||
is always first, followed by PKGNAME (if necessary), CATEGORIES,
|
||||
KEYWORDs (if necessary) and then MASTER_SITES, and optionally
|
||||
EXTRACT_SUFX or DISTFILES]
|
||||
DISTNAME= xdvi
|
||||
PKGNAME= xdvi-pl18
|
||||
CATEGORIES+= printing
|
||||
[don't forget the trailing slash ("/")!]
|
||||
MASTER_SITES= ftp://crl.dec.com/pub/X11/contrib/applications/
|
||||
[set this if the source is not in the standard ".tar.gz" form]
|
||||
EXTRACT_SUFX= .tar.Z
|
||||
|
||||
[section for distributed patches -- can be empty]
|
||||
PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/
|
||||
PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz
|
||||
|
||||
[maintainer; *mandatory*! This is the person (preferably with commit
|
||||
privileges) who a user can contact for questions and bug reports - this
|
||||
person should be the porter or someone who can forward questions to the
|
||||
original porter reasonably promptly. If you really don't want to have your
|
||||
address here, set it to "ports@FreeBSD.ORG".]
|
||||
MAINTAINER= asami@FreeBSD.ORG
|
||||
|
||||
[dependencies -- can be empty]
|
||||
RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript
|
||||
LIB_DEPENDS= Xpm\\.4\\.:${PORTSDIR}/graphics/xpm
|
||||
|
||||
[this section is for other standard bsd.port.mk variables that don't belong to
|
||||
any of the above]
|
||||
[If it extracts to a directory other than ${DISTNAME}...]
|
||||
WRKSRC= ${WRKDIR}/xdvi-new
|
||||
[If it asks questions during configure, build, install...]
|
||||
IS_INTERACTIVE= yes
|
||||
[If it requires "configure" in the distributed source directory to be run...]
|
||||
HAS_CONFIGURE= yes
|
||||
[If it requires GNU make, not /usr/bin/make, to build...]
|
||||
USE_GMAKE= yes
|
||||
[If it is an X application and requires "xmkmf -a" to be run...]
|
||||
USE_IMAKE= yes
|
||||
[et cetera.]
|
||||
|
||||
[non-standard variables to be used in the rules below]
|
||||
MY_FAVORITE_RESPONSE= "yeah, right"
|
||||
|
||||
[then the special rules, in the order they are called]
|
||||
pre-fetch:
|
||||
i go fetch something, yeah
|
||||
|
||||
post-patch:
|
||||
i need to do something after patch, great
|
||||
|
||||
pre-install:
|
||||
and then some more stuff before installing, wow
|
||||
|
||||
[and then the epilogue]
|
||||
.include <bsd.port.mk>
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1>
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: relnotes.sgml,v 1.4 1995-08-29 01:42:43 jfieber Exp $ -->
|
||||
<!-- $Id: relnotes.sgml,v 1.5 1995-10-07 04:31:38 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!--
|
||||
|
|
@ -176,8 +176,8 @@
|
|||
<tt>i386/isa/diskslice_machdep.c</tt> <tt>i386/isa/wd.c</tt>
|
||||
<tt>scsi/sd.c</tt> <tt>dev/vn/vn.c</tt>
|
||||
|
||||
<tag>Support for Ontrack Disk Manager Version
|
||||
6.0</tag> Support has been added for disks
|
||||
<tag>Support for Ontrack Disk Manager Version 6.0</tag>
|
||||
Support has been added for disks
|
||||
which use Ontrack Disk Manager. The fdisk
|
||||
program does <em>not</em> know about it
|
||||
however, so make all changes using the install
|
||||
|
|
@ -203,8 +203,8 @@
|
|||
|
||||
<p><descrip>
|
||||
|
||||
<tag>Matsushita/Panasonic (Creative) CD-ROM
|
||||
driver</tag> The Matsushita/Panasonic CR-562 and
|
||||
<tag>Matsushita/Panasonic (Creative) CD-ROM driver</tag>
|
||||
The Matsushita/Panasonic CR-562 and
|
||||
CR-563 drives are now supported when connected to
|
||||
a Sound Blaster or 100% compatible host adapter.
|
||||
Up to four host adapters are supported for a
|
||||
|
|
@ -236,8 +236,8 @@
|
|||
Sources involved: <tt>isa/aic7770.c</tt> <tt>pci/aic7870.c</tt>
|
||||
<tt>i386/scsi/*</tt> <tt>sys/dev/aic7xxx/*</tt>
|
||||
|
||||
<tag>NCR5380/NCR53400 SCSI (ProAudio Spectrum)
|
||||
driver</tag> Owner: core
|
||||
<tag>NCR5380/NCR53400 SCSI (ProAudio Spectrum) driver</tag>
|
||||
Owner: core
|
||||
|
||||
Submitted by: Serge Vakulenko (vak@cronyx.ru)
|
||||
|
||||
|
|
@ -255,8 +255,8 @@
|
|||
|
||||
<p><descrip>
|
||||
|
||||
<tag>SDL Communications Riscom/8 Serial Board
|
||||
Driver</tag> Owner: Andrey Chernov
|
||||
<tag>SDL Communications Riscom/8 Serial Board Driver</tag>
|
||||
Owner: Andrey Chernov
|
||||
(ache@FreeBSD.org)
|
||||
|
||||
Sources involved: <tt>isa/rc.c</tt> <tt>isa/rcreg.h</tt>
|
||||
|
|
@ -375,7 +375,7 @@
|
|||
|
||||
Sources involved: <tt>isa/joy.c</tt>
|
||||
|
||||
<tag>National Instruments "LabPC" driver</tag> Owner:
|
||||
<tag>National Instruments ``LabPC'' driver</tag> Owner:
|
||||
Peter Dufault (dufault@hda.com)
|
||||
|
||||
Sources involved: <tt>isa/labpc.c</tt>
|
||||
|
|
@ -398,8 +398,8 @@
|
|||
Sources involved: <tt>isa/sound/vat_audio.c</tt>
|
||||
<tt>isa/sound/vat_audioio.h</tt>
|
||||
|
||||
<tag>National Instruments AT-GPIB and AT-GPIB/TNT
|
||||
GPIB driver</tag> Owner: core
|
||||
<tag>National Instruments AT-GPIB and AT-GPIB/TNT GPIB driver</tag>
|
||||
Owner: core
|
||||
|
||||
Submitted by: Fred Cawthorne
|
||||
(fcawth@delphi.umd.edu)
|
||||
|
|
|
|||
279
handbook/routing.sgml
Normal file
279
handbook/routing.sgml
Normal file
|
|
@ -0,0 +1,279 @@
|
|||
<!-- $Id: routing.sgml,v 1.1 1995-10-07 04:31:41 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
<!-- <!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'> -->
|
||||
|
||||
<sect><heading>Gateways and routes<label id="routing"></heading>
|
||||
|
||||
<p><em>Contributed by &a.gryphon;.<newline>6 October 1995.</em>
|
||||
|
||||
For one machine to be able to find another, there must be a
|
||||
mechanism in place to describe how to get from one to the
|
||||
other. This is called Routing. A ``route'' is a defined
|
||||
pair of addresses: a <bf>destination</bf> and a
|
||||
<bf>gateway</bf>. The pair indicates that if you are
|
||||
trying to get to this <em>destination</em>, send along
|
||||
through this <em>gateway</em>. There are three types of
|
||||
destinations: individual hosts, subnets, and ``default''. The
|
||||
``default route'' is used if none of the other routes
|
||||
apply. We will talk a little bit more about default routes
|
||||
later on. There are also three types of gateways:
|
||||
individual hosts, interfaces (also called ``links''), and
|
||||
ethernet hardware addresses.
|
||||
|
||||
<sect1><heading>An example</heading>
|
||||
|
||||
<p>To illustrate different aspects of routing, we will use
|
||||
the following example which is the output of the command
|
||||
<tt>netstat -r</tt>:
|
||||
|
||||
<tscreen><verb>
|
||||
Destination Gateway Flags Refs Use Netif Expire
|
||||
|
||||
default outside-gw UGSc 37 418 ppp0
|
||||
localhost localhost UH 0 181 lo0
|
||||
test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77
|
||||
10.20.30.255 link#1 UHLW 1 2421
|
||||
foobar.com link#1 UC 0 0
|
||||
host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0
|
||||
host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 =>
|
||||
host2.foobar.com link#1 UC 0 0
|
||||
224 link#1 UC 0 0
|
||||
</verb></tscreen>
|
||||
|
||||
The first two lines specify the default route (which we
|
||||
will cover in the next section) and the <tt>localhost</tt> route.
|
||||
|
||||
The interface (<tt>Netif</tt> column) that it specifies to use
|
||||
for <tt>localhost</tt> is <tt>lo0</tt>, also known as the
|
||||
loopback device. This says to keep all traffic for this
|
||||
destination internal, rather than sending it out over the
|
||||
LAN, since it will only end up back where it started
|
||||
anyway.
|
||||
|
||||
The next thing that stands out are the
|
||||
``<tt>0:e0:...</tt>'' addresses. These are ethernet
|
||||
hardware addresses. FreeBSD will automatically identify any
|
||||
hosts (<tt>test0</tt> in the example) on the local ethernet and
|
||||
add a route for that host, directly to it over the ethernet
|
||||
interface, <tt>ed0</tt>. There is also a timeout
|
||||
(<tt>Expire</tt> column) associated with this type of route,
|
||||
which is used if we fail to hear from the host in a
|
||||
specific amount of time. In this case the route will be
|
||||
automatically deleted. These hosts are identified using a
|
||||
mechanism known as RIP (Routing Information Protocol),
|
||||
which figures out routes to local hosts based upon a
|
||||
shortest path determination.
|
||||
|
||||
FreeBSD will also add subnet routes for the local subnet
|
||||
(<tt>10.20.30.255</tt> is the broadcast address for the subnet
|
||||
<tt>10.20.30</tt>, and <tt>foobar.com</tt> is the domain name
|
||||
associated with that subnet). The designation <tt>link#1</tt>
|
||||
refers to the first ethernet card in the machine. You'll
|
||||
notice no additional interface is specified for those.
|
||||
|
||||
Both of these groups (local network hosts and local
|
||||
subnets) have their routes automatically configured by a
|
||||
daemon called <tt>routed</tt>. If this is not run, then only
|
||||
routes which are statically defined (ie. entered
|
||||
explicitly) will exist.
|
||||
|
||||
The <tt>host1</tt> line refers to our host, which it knows by
|
||||
ethernet address. Since we are the sending host, FreeBSD
|
||||
knows to use the loopback interface (<tt>lo0</tt>) rather than
|
||||
sending it out over the ethernet interface.
|
||||
|
||||
The two <tt>host2</tt> lines are an example of what happens
|
||||
when we use an ifconfig alias (see the section of ethernet
|
||||
for reasons why we would do this). The <tt>=></tt>
|
||||
symbol after the <tt>lo0</tt> interface says that not only are
|
||||
we using the loopback (since this is address also refers to
|
||||
the local host), but specifically it is an alias. Such
|
||||
routes only show up on the host that supports the alias;
|
||||
all other hosts on the local network will simply have a
|
||||
<tt>link#1</tt> line for such.
|
||||
|
||||
The final line (destination subnet <tt>224</tt>) deals with
|
||||
MultiCasting, which will be covered in a another section.
|
||||
|
||||
The other column that we should talk about are the
|
||||
<tt>Flags</tt>. Each route has different attributes that are
|
||||
described in the column. Below is a short table of some of
|
||||
these flags and their meanings:
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag/U/ <bf/Up:/ The route is active.
|
||||
|
||||
<tag/H/ <bf/Host:/ The route destination is a single host.
|
||||
|
||||
<tag/G/ <bf/Gateway:/ Send anything for this destination
|
||||
on to this remote system, which will figure out from
|
||||
there where to send it.
|
||||
|
||||
<tag/S/ <bf/Static:/ This route was configured manually,
|
||||
not automatically generated by the system.
|
||||
|
||||
<tag/C/ <bf/Clone:/ Generates a new route based upon this
|
||||
route for machines we connect to. This type of route is
|
||||
normally used for local networks.
|
||||
|
||||
<tag/W/ <bf/WasCloned/ Indicated a route that was
|
||||
auto-configured based upon a local area network (Clone)
|
||||
route.
|
||||
|
||||
<tag/L/ <bf/Link:/ Route involves references to ethernet
|
||||
hardware.
|
||||
|
||||
</descrip>
|
||||
|
||||
|
||||
<sect1><heading>Default routes</heading>
|
||||
|
||||
<p>When the local system needs to make a connection to
|
||||
remote host, it checks the routing table to determine if
|
||||
a known path exists. If the remote host falls into a
|
||||
subnet that we know how to reach (Cloned routes), then
|
||||
the system checks to see if it can connect along that
|
||||
interface.
|
||||
|
||||
If all known paths fail, the system has one last option:
|
||||
the <bf>default</bf> route. This route is a special type
|
||||
of gateway route (usually the only one present in the
|
||||
system), and is always marked with a ``<tt>c</tt>'' in
|
||||
the flags field. For hosts on a local area network, this
|
||||
gateway is set to whatever machine has a direct
|
||||
connection to the outside world (whether via PPP link, or
|
||||
your hardware device attached to a dedicated data line).
|
||||
|
||||
If you are configuring the default route for a machine
|
||||
which itself is functioning as the gateway to the outside
|
||||
world, then the default route will be the gateway machine
|
||||
at your Internet Service Provider's (ISP) site.
|
||||
|
||||
Let's look at an example of default routes. This is a
|
||||
common configuration:
|
||||
<tscreen><verb>
|
||||
[Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW]
|
||||
</verb></tscreen>
|
||||
|
||||
The hosts <tt>Local1</tt> and <tt>Local2</tt> are at your
|
||||
site, with the formed being your PPP connection to your
|
||||
ISP's Terminal Server. Your ISP has a local network at
|
||||
their site, which has, among other things, the server
|
||||
where you connect and a hardware device (T1-GW) attached
|
||||
to the ISP's internet feed.
|
||||
|
||||
The default routes for each of your machines will be:
|
||||
|
||||
<tscreen><verb>
|
||||
host default gateway interface
|
||||
---- --------------- ---------
|
||||
Local2 Local1 ethernet
|
||||
Local1 T1-GW PPP
|
||||
</verb></tscreen>
|
||||
|
||||
A common question is ``Why (or how) would we set the
|
||||
T1-GW to be the default gateway for Local1, rather than
|
||||
the ISP server it is connected to?''.
|
||||
|
||||
Remember, since the PPP interface is using an address on
|
||||
the ISP's local network for your side of the connection,
|
||||
routes for any other machines on the ISP's local network
|
||||
will be automatically generated. Hence, you will already
|
||||
know how to reach the T1-GW machine, so there is no need
|
||||
for the intermediate step of sending traffic to the ISP
|
||||
server.
|
||||
|
||||
As a final note, it is common to use the address ``<tt>...1</tt>''
|
||||
as the gateway address for your local network. So (using
|
||||
the same example), if your local class-C address space
|
||||
was <tt>10.20.30</tt> and your ISP was using <tt>10.9.9</tt> then the
|
||||
default routes would be:
|
||||
|
||||
<tscreen><verb>
|
||||
Local2 (10.20.30.2) --> Local1 (10.20.30.1)
|
||||
Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1)
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1><heading>Dual homed hosts</heading>
|
||||
|
||||
<p>There is one other type of configuration that we should
|
||||
cover, and that is a host that sits on two different
|
||||
networks. Technically, any machine functioning as a
|
||||
gateway (in the example above, using a PPP connection)
|
||||
counts as a dual-homed host. But the term is really only
|
||||
used to refer to a machine that sits on two local-area
|
||||
networks.
|
||||
|
||||
In one case, the machine as two ethernet cards, each
|
||||
having an address on the seperate subnets. Alternately,
|
||||
the machine may only have one ethernet card, and be using
|
||||
ifconfig aliasing. The former is used if two physically
|
||||
separate ethernet networks are in use, the latter if
|
||||
there is one physical network segment, but two logically
|
||||
seperate subnets.
|
||||
|
||||
Either way, routing tables are set up so that each subnet
|
||||
knows that this machine is the defined gateway (inbound
|
||||
route) to the other subnet. This configuration, with the
|
||||
machine acting as a Bridge between the two subnets, is
|
||||
often used when we need to implement packet filtering or
|
||||
firewall security in either or both directions.
|
||||
|
||||
<sect1><heading>Routing propogation</heading>
|
||||
|
||||
<p>We have already talked about how we define our routes to
|
||||
the outside world, but not about how the outside world
|
||||
finds us.
|
||||
|
||||
We already know that routing tables can be set up so that
|
||||
all traffic for a particular address space (in our
|
||||
examples, a class-C subnet) can be sent to a particular
|
||||
host on that network, which will forward the packets
|
||||
inbound.
|
||||
|
||||
When you get an address space assigned to your site, your
|
||||
service provider will set up their routing tables so that
|
||||
all traffic for your subnet will be sent down your PPP
|
||||
link to your site. But how do sites across the country
|
||||
know to send to your ISP?
|
||||
|
||||
There is a system (much like the distributed DNS
|
||||
information) that keeps track of all assigned
|
||||
address-spaces, and defines their point of connection to
|
||||
the Internet Backbone. The ``Backbone'' are the main
|
||||
trunk lines that carry internet traffic across the
|
||||
country, and around the world. Each backbone machine has
|
||||
a copy of a master set of tables, which direct traffic
|
||||
for a particular network to a specific backbone carrier,
|
||||
and from there down the chain of service providers until
|
||||
it reaches your network.
|
||||
|
||||
It is the task of your service provider to advertise to
|
||||
the backbone sites that they are the point of connection
|
||||
(and thus the path inward) for your site. This is known
|
||||
as route propogation.
|
||||
|
||||
<!--
|
||||
<sect1><heading>Multicast Routing</heading>
|
||||
-->
|
||||
|
||||
<sect1><heading>Troubleshooting</heading>
|
||||
|
||||
<p>Sometimes, there is a problem with routing propogation,
|
||||
and some sites are unable to connect to you. Perhaps the
|
||||
most useful command for trying to figure out where a
|
||||
routing is breaking down is the <tt>traceroute(8)</tt>
|
||||
command. It is equally useful if you cannot seem to make
|
||||
a connection to a remote machine (ie. <tt>ping(8)</tt>
|
||||
fails).
|
||||
|
||||
The <tt>traceroute(8)</tt> command is run with the name
|
||||
of the remote host you are trying to connect to. It will
|
||||
show the gateway hosts along the path of the attempt,
|
||||
eventually either reaching the target host, or
|
||||
terminating because of a lack of connection.
|
||||
|
||||
For more information, see the manual page for
|
||||
<tt>traceroute(8)</tt>.
|
||||
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: scsi.sgml,v 1.5 1995-09-27 00:46:28 jmz Exp $ -->
|
||||
<!-- $Id: scsi.sgml,v 1.6 1995-10-07 04:31:46 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!--
|
||||
|
|
@ -15,7 +15,7 @@
|
|||
-->
|
||||
<sect><heading>SCSI<label id="scsi"></heading>
|
||||
|
||||
<p><em>© 1995, &a.wilko;.<newline>3 September 1995.</em>
|
||||
<p><em>Copyright © 1995, &a.wilko;.<newline>3 September 1995.</em>
|
||||
|
||||
SCSI is an acronym for Small Computer Systems Interface. It is an
|
||||
ANSI standard that has become one of the leading I/O buses in the
|
||||
|
|
@ -163,7 +163,7 @@
|
|||
0 Volts (indeed, TTL levels) and are relative to a COMMON
|
||||
ground reference. A singled ended 8 bit SCSI bus has
|
||||
approximately 25 ground lines, who are all tied to a single
|
||||
'rail' on all devices. A standard single ended bus has a
|
||||
`rail' on all devices. A standard single ended bus has a
|
||||
maximum length of 6 meters. If the same bus is used with
|
||||
fast-SCSI devices, the maximum length allowed drops to 3
|
||||
meters. Fast-SCSI means that instead of 5Mbytes/sec the bus
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: sections.sgml,v 1.4 1995-10-01 04:43:15 jfieber Exp $ -->
|
||||
<!-- $Id: sections.sgml,v 1.5 1995-10-07 04:31:53 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!-- Entities containing all the pieces of the handbook are -->
|
||||
|
|
@ -32,6 +32,7 @@
|
|||
<!ENTITY ppp SYSTEM "ppp.sgml">
|
||||
<!ENTITY printing SYSTEM "printing.sgml">
|
||||
<!ENTITY relnotes SYSTEM "relnotes.sgml">
|
||||
<!ENTITY routing SYSTEM "routing.sgml">
|
||||
<!ENTITY scsi SYSTEM "scsi.sgml">
|
||||
<!ENTITY skey SYSTEM "skey.sgml">
|
||||
<!ENTITY slipc SYSTEM "slipc.sgml">
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: skey.sgml,v 1.2 1995-09-26 19:12:28 wollman Exp $ -->
|
||||
<!-- $Id: skey.sgml,v 1.3 1995-10-07 04:31:56 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
<!--
|
||||
Copyright 1995 Massachusetts Institute of Technology
|
||||
|
|
@ -190,7 +190,7 @@ s/key 92 hi52030
|
|||
Password:
|
||||
</verb></tscreen>
|
||||
|
||||
>Note that, before prompting for a password, the login program
|
||||
Note that, before prompting for a password, the login program
|
||||
prints out the iteration number and seed which you will need in order
|
||||
to generate the appropriate key. You will also find a useful feature
|
||||
(not shown here): if you press return at the password prompt, the
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: slipc.sgml,v 1.3 1995-08-09 03:43:48 jfieber Exp $ -->
|
||||
<!-- $Id: slipc.sgml,v 1.4 1995-10-07 04:31:59 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>Setting up a SLIP client<label id="slipc"></heading>
|
||||
|
|
@ -17,10 +17,10 @@ mileage may vary.
|
|||
-->
|
||||
|
||||
First, determine which serial port your modem is connected to. I have
|
||||
a symbolic link /dev/modem -> cuaa1, and only use the modem name in my
|
||||
a symbolic link <tt>/dev/modem -> cuaa1</tt>, and only use the modem name in my
|
||||
configuration files. It can become quite cumbersome when you need to
|
||||
fix a bunch of files in /etc and .kermrc's all over the system! (Note
|
||||
that /dev/cuaa0 is COM1, cuaa1 is COM2, etc.)
|
||||
fix a bunch of files in <tt>/etc</tt> and <tt>.kermrc</tt>'s all over the system! (Note
|
||||
that <tt>/dev/cuaa0</tt> is COM1, <tt>cuaa1</tt> is COM2, etc.)
|
||||
|
||||
Make sure you have
|
||||
<verb>
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: submitters.sgml,v 1.7 1995-09-27 00:46:29 jmz Exp $ -->
|
||||
<!-- $Id: submitters.sgml,v 1.8 1995-10-07 04:32:03 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<chapt><heading>Contributing to FreeBSD<label id="submitters"></heading>
|
||||
|
|
@ -82,11 +82,11 @@ are each, in their own way, quite significant to the project.
|
|||
FreeBSD maintainers. This is done with the <tt>diff(1)</tt> command,
|
||||
with the `context diff' form being preferred. For example:
|
||||
<tscreen><verb>
|
||||
diff -c <oldfile> <newfile>
|
||||
diff -c oldfile newfile
|
||||
</verb></tscreen>
|
||||
or
|
||||
<tscreen><verb>
|
||||
diff -c -r <olddir> <newdir>
|
||||
diff -c -r olddir newdir
|
||||
</verb></tscreen>
|
||||
would generate such a set of context diffs for the given source file
|
||||
or directory hierarchy. See the man page for <tt>diff(1)</tt> for more
|
||||
|
|
@ -193,7 +193,7 @@ THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|||
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
|
||||
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
$Id: submitters.sgml,v 1.7 1995-09-27 00:46:29 jmz Exp $
|
||||
$Id: submitters.sgml,v 1.8 1995-10-07 04:32:03 jfieber Exp $
|
||||
</verb></tscreen>
|
||||
For your convenience, a copy of this text can be found in
|
||||
<tt>/usr/share/examples/etc/bsd-style-copyright</tt>.
|
||||
|
|
|
|||
Loading…
Reference in a new issue