Spelling, grammar cleanups
This commit is contained in:
James Raynard
parent
040d6afbbe
commit
f10114b093
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=2078
12 changed files with 114 additions and 114 deletions
|
|
@ -3,7 +3,7 @@
|
|||
|
||||
This conversion has been made by Ollivier Robert.
|
||||
|
||||
$Id: booting.sgml,v 1.13 1997-02-22 12:58:10 peter Exp $
|
||||
$Id: booting.sgml,v 1.14 1997-10-19 13:32:04 jraynard Exp $
|
||||
|
||||
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN">
|
||||
|
|
@ -14,7 +14,7 @@
|
|||
<author>Poul-Henning Kamp, <tt/<phk@login.dknet.dk>/</author>
|
||||
<date>v1.1, April 26th</date>
|
||||
<abstract>
|
||||
Booting FreeBSD is essentially a three step: Load the kernel,
|
||||
Booting FreeBSD is essentially a three step process: load the kernel,
|
||||
determine the root filesystem and initialize user-land things. This
|
||||
leads to some interesting possibilities as shown below...
|
||||
</abstract>
|
||||
|
|
@ -26,7 +26,7 @@
|
|||
|
||||
<p><em>Contributed by &a.phk;. v1.1, April 26th.</em>
|
||||
|
||||
Booting FreeBSD is essentially a three step: Load the kernel,
|
||||
Booting FreeBSD is essentially a three step process: load the kernel,
|
||||
determine the root filesystem and initialize user-land things. This
|
||||
leads to some interesting possibilities shown below.
|
||||
|
||||
|
|
@ -34,14 +34,14 @@
|
|||
<p>
|
||||
We presently have three basic mechanisms for loading the
|
||||
kernel as described below:
|
||||
They all pass some
|
||||
they all pass some
|
||||
information to the kernel to help the kernel decide what to do
|
||||
next.
|
||||
|
||||
<descrip>
|
||||
<tag>Biosboot</tag>
|
||||
|
||||
Biosboot is our ``bootblocks'', it consists of two files, which
|
||||
Biosboot is our ``bootblocks''. It consists of two files which
|
||||
will be installed in the first 8Kbytes of the floppy or hard-disk
|
||||
slice to be booted from.
|
||||
|
||||
|
|
@ -71,7 +71,7 @@
|
|||
<p>
|
||||
Once the kernel is loaded and the boot-code jumps to it, the kernel
|
||||
will initialize itself, trying to determine what hardware is
|
||||
present and so on, and then it needs to find a root filesystem.
|
||||
present and so on; it then needs to find a root filesystem.
|
||||
|
||||
Presently we support the following types of root filesystems:
|
||||
|
||||
|
|
@ -83,15 +83,15 @@
|
|||
|
||||
<tag>MSDOS</tag>
|
||||
|
||||
While this is technically possible, it is not particular useful,
|
||||
because of ``FAT'' filesystems inability to make links, device
|
||||
nodes and such ``UNIXisms''.
|
||||
While this is technically possible, it is not particular useful
|
||||
because of the ``FAT'' filesystem's inability to deal with links,
|
||||
device nodes and other such ``UNIXisms''.
|
||||
|
||||
<tag>MFS</tag>
|
||||
|
||||
This is actually a UFS filesystem which has been compiled into
|
||||
the kernel. That means that the kernel does not really need any
|
||||
disks/floppies or other HW to function.
|
||||
hard disks, floppies or other hardware to function.
|
||||
|
||||
<tag>CD9660</tag>
|
||||
|
||||
|
|
@ -106,16 +106,16 @@
|
|||
|
||||
<sect1><heading>Initialize user-land things</heading>
|
||||
<p>
|
||||
To get the user-land going, when the kernel has finished
|
||||
initialization, it will create a process with ``<tt/pid == 1/'' and execute
|
||||
a program on the root filesystem, this program is normally
|
||||
To get the user-land going, the kernel, when it has finished
|
||||
initialization, will create a process with ``<tt/pid == 1/'' and execute
|
||||
a program on the root filesystem; this program is normally
|
||||
``<tt>/sbin/init</tt>''.
|
||||
|
||||
You can substitute any program for /sbin/init, as long as you keep
|
||||
in mind that:
|
||||
|
||||
there is no stdin/out/err unless you open it yourself, if you exit,
|
||||
the machine panics, signal handling is special for ``<tt/pid ==
|
||||
there is no stdin/out/err unless you open it yourself. If you exit,
|
||||
the machine panics. Signal handling is special for ``<tt/pid ==
|
||||
1/''.
|
||||
|
||||
An example of this is the ``<tt>/stand/sysinstall</tt>''
|
||||
|
|
@ -139,7 +139,7 @@
|
|||
(etc...)<newline>
|
||||
</itemize>
|
||||
|
||||
Now you run FreeBSD without repartitioning your hard disk...
|
||||
Now you are running FreeBSD without repartitioning your hard disk...
|
||||
|
||||
<tag/B -- Using NFS/
|
||||
|
||||
|
|
@ -147,25 +147,25 @@
|
|||
<tt>/nfs</tt>, chroots to <tt>/nfs</tt> and executes
|
||||
<tt>/sbin/init</tt> there
|
||||
|
||||
Now you run FreeBSD diskless, even though you do not control
|
||||
Now you are running FreeBSD diskless, even though you do not control
|
||||
the NFS server...
|
||||
|
||||
<tag/C -- Start an X-server/
|
||||
|
||||
Now you have an X-terminal, which is better than that dingy
|
||||
X-under-windows-so-slow-you-can-see-what-it-does thing that
|
||||
your boss insist is better than forking our money on HW.
|
||||
your boss insist is better than forking out money on hardware.
|
||||
|
||||
<tag/D -- Using a tape/
|
||||
Takes a copy of <tt>/dev/rwd0</tt> and writes it to a remote tape
|
||||
station or fileserver.
|
||||
|
||||
Now you finally got that backup you should have made a year
|
||||
Now you finally get that backup you should have made a year
|
||||
ago...
|
||||
|
||||
<tag>E -- Acts as a firewall/web-server/what do I know...</tag>
|
||||
|
||||
This is particular interesting since you can boot from a write-
|
||||
This is particularly interesting since you can boot from a write-
|
||||
protected floppy, but still write to your root filesystem...
|
||||
</descrip>
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
#
|
||||
# Converted by Ollivier Robert <roberto@FreeBSD.ORG>
|
||||
#
|
||||
# $Id: ctm.sgml,v 1.20 1997-08-11 13:36:04 eivind Exp $
|
||||
# $Id: ctm.sgml,v 1.21 1997-10-19 13:32:08 jraynard Exp $
|
||||
#
|
||||
# ----------------------------------------------------------------------------
|
||||
# "THE BEER-WARE LICENSE" (Revision 42):
|
||||
|
|
@ -92,10 +92,10 @@
|
|||
special ``base'' delta that provides the starting point for all
|
||||
deltas produced subsequently to it.
|
||||
|
||||
You can recognize a base delta by the ``<tt/A/'' appended to the
|
||||
number (<tt/src-cur.0341A.gz/ for instance). As a rule a base
|
||||
You can recognize a base delta by the ``<tt/Empty/'' appended to the
|
||||
number (<tt/src-cur.0341Empty.gz/ for instance). As a rule a base
|
||||
delta is produced every 100 deltas, the next one will be
|
||||
<tt/src-cur.0400A.gz/. By the way, they are large! 25 to 30
|
||||
<tt/src-cur.0400Empty.gz/. By the way, they are large! 50 to 100
|
||||
Megabytes of <tt/gzip/'ed data is common for a base delta.
|
||||
|
||||
<!--
|
||||
|
|
@ -150,7 +150,7 @@ ctm -v -v /where/you/store/your/deltas/src-cur.*
|
|||
This behaviour gives us a simple way to maintain local changes:
|
||||
simply copy the files you plan to modify to the corresponding
|
||||
file names with a <tt>.ctm</tt> suffix. Then you can freely hack
|
||||
the code, while CTM keeps the <tt>.ctm</tt> file upto-date.
|
||||
the code, while CTM keeps the <tt>.ctm</tt> file up-to-date.
|
||||
|
||||
<sect2><heading>Other interesting CTM options</heading>
|
||||
<sect3><heading>Finding out exactly what would be touched by an update</heading>
|
||||
|
|
@ -181,7 +181,7 @@ ctm -v -v /where/you/store/your/deltas/src-cur.*
|
|||
specifying filtering regular expressions using the
|
||||
``<tt>-e</tt>'' and ``<tt>-x</tt>'' options.
|
||||
<p>
|
||||
For example, to extract an upto-date copy of
|
||||
For example, to extract an up-to-date copy of
|
||||
<tt>lib/libc/Makefile</tt> from your collection of saved CTM deltas,
|
||||
run the commands:
|
||||
<tscreen><verb>
|
||||
|
|
@ -216,22 +216,22 @@ ctm -e '^lib/libc/Makefile' ~ctm/src-cur.*
|
|||
included. You will get the ``international'' version only. If
|
||||
sufficient interest appears, we will set up a ``<tt/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
|
||||
<tt/ftp/ or <tt/rcp/ to a machine closer to you. You need to have
|
||||
earned this, since it takes time to do, but I will be all the more
|
||||
happy to do it for you then.
|
||||
|
||||
-->
|
||||
There is a sequence of deltas for the <tt/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 will consider setting it up.
|
||||
|
||||
<!--
|
||||
If you have commit privileges or are similarly authorized by the
|
||||
FreeBSD core team, you can also get access to the CVS repository
|
||||
tree by the same means. Contact &a.phk;
|
||||
for details.
|
||||
|
||||
-->
|
||||
|
||||
<sect2><heading>Thanks!</heading>
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: cvsup.sgml,v 1.29 1997-10-14 03:14:00 jdp Exp $ -->
|
||||
<!-- $Id: cvsup.sgml,v 1.30 1997-10-19 13:32:08 jraynard Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect1><heading>CVSup<label id="cvsup"></heading>
|
||||
|
|
@ -49,7 +49,7 @@ binary package versions due to the fact that it requires a version of
|
|||
the C library that does not yet exist in FreeBSD-2.1.{6,7}. You can easily
|
||||
use <url url="ftp://ftp.freebsd.org/pub/FreeBSD/ports-current/net/cvsup.tar.gz"
|
||||
name="the port">, however, just as with FreeBSD 2.2. Simply unpack
|
||||
the tar file, cd to the cvsup subdirectory and type "make install"
|
||||
the tar file, cd to the cvsup subdirectory and type "make install".
|
||||
|
||||
<p>Because CVSup is written in <url
|
||||
url="http://www.research.digital.com/SRC/modula-3/html/home.html"
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: dma.sgml,v 1.9 1997-10-09 22:51:31 uhclem Exp $ -->
|
||||
<!-- $Id: dma.sgml,v 1.10 1997-10-19 13:32:09 jraynard Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!--
|
||||
|
|
@ -625,12 +625,12 @@ software compatibility.
|
|||
0x41e read Channel 5 Scatter-Gather Status Register
|
||||
0x41f read Channel 7 Scatter-Gather Status Register
|
||||
|
||||
0x420-0x423 r/w Channel 0 Scatter-Gather Descripter Table Pointer Register
|
||||
0x424-0x427 r/w Channel 1 Scatter-Gather Descripter Table Pointer Register
|
||||
0x428-0x42b r/w Channel 2 Scatter-Gather Descripter Table Pointer Register
|
||||
0x42c-0x42f r/w Channel 3 Scatter-Gather Descripter Table Pointer Register
|
||||
0x434-0x437 r/w Channel 5 Scatter-Gather Descripter Table Pointer Register
|
||||
0x438-0x43b r/w Channel 6 Scatter-Gather Descripter Table Pointer Register
|
||||
0x43c-0x43f r/w Channel 7 Scatter-Gather Descripter Table Pointer Register
|
||||
0x420-0x423 r/w Channel 0 Scatter-Gather Descriptor Table Pointer Register
|
||||
0x424-0x427 r/w Channel 1 Scatter-Gather Descriptor Table Pointer Register
|
||||
0x428-0x42b r/w Channel 2 Scatter-Gather Descriptor Table Pointer Register
|
||||
0x42c-0x42f r/w Channel 3 Scatter-Gather Descriptor Table Pointer Register
|
||||
0x434-0x437 r/w Channel 5 Scatter-Gather Descriptor Table Pointer Register
|
||||
0x438-0x43b r/w Channel 6 Scatter-Gather Descriptor Table Pointer Register
|
||||
0x43c-0x43f r/w Channel 7 Scatter-Gather Descriptor Table Pointer Register
|
||||
</verb>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: kernelconfig.sgml,v 1.29 1997-08-12 09:18:00 asami Exp $ -->
|
||||
<!-- $Id: kernelconfig.sgml,v 1.30 1997-10-19 13:32:09 jraynard Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
<!-- <!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'> -->
|
||||
<chapt><heading>Configuring the FreeBSD Kernel<label id="kernelconfig"></heading>
|
||||
|
|
@ -14,7 +14,7 @@
|
|||
|
||||
<p>Building a custom kernel is one of the most important
|
||||
rites of passage every Unix system administrator must
|
||||
learn. This process, while time-consuming, will provide
|
||||
endure. This process, while time-consuming, will provide
|
||||
many benefits to your FreeBSD system. Unlike the GENERIC
|
||||
kernel, which must support every possible SCSI and
|
||||
network card, along with tons of other rarely used
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: kerneldebug.sgml,v 1.16 1997-08-12 09:18:01 asami Exp $ -->
|
||||
<!-- $Id: kerneldebug.sgml,v 1.17 1997-10-19 13:32:10 jraynard Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<chapt><heading>Kernel Debugging<label id="kerneldebug"></heading>
|
||||
|
|
@ -8,7 +8,7 @@
|
|||
<sect><heading>Debugging a Kernel Crash Dump with KGDB</heading>
|
||||
|
||||
<p>Here are some instructions for getting kernel debugging
|
||||
working on a crash dump, it assumes that you have enough swap
|
||||
working on a crash dump. They assume that you have enough swap
|
||||
space for a crash dump. If you have multiple swap
|
||||
partitions and the first one is too small to hold the dump,
|
||||
you can configure your kernel to use an alternate dump device
|
||||
|
|
@ -26,7 +26,7 @@
|
|||
normally arranged via <tt>/etc/rc.conf</tt> and <tt>/etc/rc</tt>.
|
||||
Alternatively, you can
|
||||
hard-code the dump device via the `dump' clause in the `config' line
|
||||
of your kernel config file. This is deprecated, use only if you
|
||||
of your kernel config file. This is deprecated and should be used only if you
|
||||
want a crash dump from a kernel that crashes during booting.
|
||||
|
||||
<em><bf>Note:</bf> In the following, the term `<tt>kgdb</tt>' refers
|
||||
|
|
@ -34,8 +34,8 @@
|
|||
either starting the <tt>gdb</tt> with the option <tt>-k</tt>, or by linking
|
||||
and starting it under the name <tt>kgdb</tt>. This is not being
|
||||
done by default, however, and the idea is basically deprecated since
|
||||
the GNU folks do not love it if their tools behave differently when
|
||||
called by another name. This feature might as well be discontinued
|
||||
the GNU folks do not like their tools to behave differently when
|
||||
called by another name. This feature may well be discontinued
|
||||
in further releases.</em>
|
||||
|
||||
When the kernel has been built make a copy of it, say
|
||||
|
|
@ -173,7 +173,7 @@
|
|||
necessary now. The stack frames are supposed to point to
|
||||
the right locations now, even in case of a trap.
|
||||
(I do not have a new core dump handy <g>, my kernel
|
||||
did not panic for ia rather long time.)
|
||||
has not panicked for a rather long time.)
|
||||
From looking at the code in source line 403,
|
||||
there is a high probability that either the pointer
|
||||
access for ``tp'' was messed up, or the array access was
|
||||
|
|
@ -232,7 +232,7 @@
|
|||
If you need to do low-level debugging on your kernel, there is
|
||||
an on-line debugger available called DDB. It allows to
|
||||
setting breakpoints, single-steping kernel functions, examining
|
||||
and changing kernel variables, etc. However, it cannot not
|
||||
and changing kernel variables, etc. However, it cannot
|
||||
access kernel source files, and only has access to the global
|
||||
and static symbols, not to the full debug information like
|
||||
<tt>kgdb</tt>.
|
||||
|
|
@ -245,18 +245,18 @@
|
|||
name="Kernel Configuration"> for details on configuring the
|
||||
FreeBSD kernel. 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
|
||||
Update the boot blocks; the recent ones load the DDB symbols
|
||||
automagically.)
|
||||
|
||||
Once your DDB kernel is running, there are several ways to
|
||||
enter DDB. The first, and earliest way is to type the boot
|
||||
flag <tt>-d</tt> 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
|
||||
probing. Hence you can 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
|
||||
Ctrl-Alt-ESC. For syscons, this can be remapped; some of
|
||||
the distributed maps do this, so watch out.
|
||||
There is an option
|
||||
available for serial consoles
|
||||
|
|
@ -264,24 +264,24 @@
|
|||
enter DDB (``<tt>options BREAK_TO_DEBUGGER</tt>''
|
||||
in the kernel config file). It is not the default since there are a lot of
|
||||
crappy serial adapters around that gratuitously generate a
|
||||
BREAK condition for example when pulling the cable.
|
||||
BREAK condition, for example when pulling the cable.
|
||||
|
||||
The third way is that any panic condition will branch to DDB if
|
||||
the kernel is configured to use it.
|
||||
For this reason, it is not wise to
|
||||
configure a kernel with DDB for a machine running unattended.
|
||||
|
||||
The DDB commands roughly resemble some <tt>gdb</tt> commands. The first you
|
||||
probably need is to set a breakpoint:
|
||||
The DDB commands roughly resemble some <tt>gdb</tt> commands. The first
|
||||
thing you probably need to do is to set a breakpoint:
|
||||
<tscreen><verb>
|
||||
b function-name
|
||||
b address
|
||||
</verb></tscreen>
|
||||
|
||||
Numbers are taken hexadecimal by default, but to make them
|
||||
distinct from symbol names, hexadecimal numbers starting with the
|
||||
distinct from symbol names; hexadecimal numbers starting with the
|
||||
letters <tt>a</tt>-<tt>f</tt> need to be preceded with
|
||||
<tt>0x</tt> (for other numbers, this is optional). Simple
|
||||
<tt>0x</tt> (this is optional for other numbers). Simple
|
||||
expressions are allowed, for example: <tt>function-name + 0x103</tt>.
|
||||
|
||||
To continue the operation of an interrupted kernel, simply type
|
||||
|
|
@ -303,7 +303,7 @@
|
|||
</verb></tscreen>
|
||||
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
|
||||
breakpoint, but you need to specify the exact address; this can be
|
||||
obtained from
|
||||
<tscreen><verb>
|
||||
show b
|
||||
|
|
@ -317,7 +317,7 @@
|
|||
<tscreen><verb>
|
||||
n
|
||||
</verb></tscreen>
|
||||
<bf>Note:</bf> this is different from <tt>gdb</tt>'s `next' statement, it is like
|
||||
<bf>Note:</bf> this is different from <tt>gdb</tt>'s `next' statement; it is like
|
||||
<tt>gdb</tt>'s `finish'.
|
||||
|
||||
To examine data from memory, use (for example):
|
||||
|
|
@ -340,14 +340,14 @@
|
|||
to disassemble the first 0x10 instructions of <tt>foofunc</tt>, and display
|
||||
them along with their offset from the beginning of <tt>foofunc</tt>.
|
||||
|
||||
To modify the memory, use the write command:
|
||||
To modify memory, use the write command:
|
||||
<tscreen><verb>
|
||||
w/b termbuf 0xa 0xb 0
|
||||
w/w 0xf0010030 0 0
|
||||
</verb></tscreen>
|
||||
The command modifier (<tt>b</tt>/<tt>h</tt>/<tt>w</tt>)
|
||||
specifies the size of the data to be written, the first
|
||||
following expression is the address to write to, the remainder
|
||||
following expression is the address to write to and the remainder
|
||||
is interpreted as data to write to successive memory locations.
|
||||
|
||||
If you need to know the current registers, use
|
||||
|
|
@ -384,7 +384,7 @@
|
|||
call diediedie()
|
||||
</verb></tscreen>
|
||||
|
||||
will cause your kernel to dump core and reboot, so you can
|
||||
This will cause your kernel to dump core and reboot, so you can
|
||||
later analyze the core on a higher level with kgdb. This
|
||||
command usually must be followed by another
|
||||
`<tt>continue</tt>' statement.
|
||||
|
|
@ -415,18 +415,18 @@
|
|||
|
||||
<sect><heading>On-line Kernel Debugging Using Remote GDB</heading>
|
||||
|
||||
<p>This feature is supported since FreeBSD 2.2, and it's actually
|
||||
<p>This feature has been supported since FreeBSD 2.2, and it's actually
|
||||
a very neat one.
|
||||
|
||||
GDB used to support <em/remote debugging/ for a long time
|
||||
already. This is done using a very simple protocol along a
|
||||
serial line. Obviously, and opposed to the other methods
|
||||
described above, you need two machines for doing this. One is
|
||||
GDB has already supported <em/remote debugging/ for a long time.
|
||||
This is done using a very simple protocol along a
|
||||
serial line. Unlike the other methods
|
||||
described above, you will need two machines for doing this. One is
|
||||
the host providing the debugging environment, including all
|
||||
the sources, and a copy of the kernel binary with all the
|
||||
symbols in it, and the other one is the target machine that
|
||||
simply runs a similar copy of the very same kernel (but stripped
|
||||
off the debugging information).
|
||||
of the debugging information).
|
||||
|
||||
You should configure the kernel in question with <tt>config -g</tt>,
|
||||
include <em/DDB/ into the configuration, and compile it as usual.
|
||||
|
|
@ -453,7 +453,7 @@ Copyright 1996 Free Software Foundation, Inc...
|
|||
(kgdb) target remote /dev/cuaa0
|
||||
</verb></tscreen>
|
||||
|
||||
Now, on the target host (that entered DDB right before even starting
|
||||
Now, on the target host (the one that entered DDB right before even starting
|
||||
the device probe), type:
|
||||
<tscreen><verb>
|
||||
Debugger("Boot flags requested debugger")
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: kernelopts.sgml,v 1.8 1997-08-12 09:18:03 asami Exp $ -->
|
||||
<!-- $Id: kernelopts.sgml,v 1.9 1997-10-19 13:32:10 jraynard Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
<!-- <!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'> -->
|
||||
|
||||
|
|
@ -13,7 +13,7 @@ id="kernelconfig" name="kernel configuration"> before reading here.
|
|||
|
||||
<p>The use of kernel options is basically described in the <ref
|
||||
id="kernelconfig:options" name="kernel configuration"> section.
|
||||
There's also an explanation about ``historic'' and ``new-style''
|
||||
There's also an explanation of ``historic'' and ``new-style''
|
||||
options. The ultimate goal is to eventually turn all the supported
|
||||
options in the kernel into new-style ones, so for people who
|
||||
correctly did a <tt/make depend/ in their kernel compile directory
|
||||
|
|
@ -36,7 +36,7 @@ id="kernelconfig" name="kernel configuration"> before reading here.
|
|||
</verb>
|
||||
<p>This way, an administrator mentioning another value for the
|
||||
option in his config file will take the default out of effect, and
|
||||
replace it with his new value. Apparently, the new value will be
|
||||
replace it with his new value. Clearly, the new value will be
|
||||
substituted into the source code during the preprocessor run, so it
|
||||
must be a valid C expression in whatever context the default value
|
||||
would have been used.
|
||||
|
|
@ -57,16 +57,16 @@ id="kernelconfig" name="kernel configuration"> before reading here.
|
|||
|
||||
<p>People familiar with the C language will immediately recognize
|
||||
that everything could be counted as a ``config option'' where
|
||||
there is at least a single <tt/#ifdef/ referencing it... Now only
|
||||
few people probably would try to say
|
||||
there is at least a single <tt/#ifdef/ referencing it... However,
|
||||
it's unlikely that many people would put
|
||||
|
||||
<verb>
|
||||
options notyet,notdef
|
||||
</verb>
|
||||
<p>in their config file however, and watch the kernel compilation
|
||||
fall over. :-)
|
||||
<p>in their config file, and then wonder why the kernel compilation
|
||||
falls over. :-)
|
||||
|
||||
<p>Apparently, using arbitrary names for the options makes it very
|
||||
<p>Clearly, using arbitrary names for the options makes it very
|
||||
hard to track their usage throughout the kernel source tree. That is
|
||||
the rationale behind the <em/new-style/ option scheme, where each
|
||||
option goes into a separate <tt/.h/ file in the kernel compile
|
||||
|
|
@ -129,9 +129,9 @@ id="kernelconfig" name="kernel configuration"> before reading here.
|
|||
#include "opt_foo.h"
|
||||
</verb>
|
||||
<p><em>on top</em>, before all the <tt/#include <xxx.h>/
|
||||
stuff. The sequence is most important in case the options will
|
||||
override some defaults from the regular include files, where the
|
||||
defaults are protected by
|
||||
stuff. This sequence is most important as the options could
|
||||
override defaults from the regular include files, if the
|
||||
defaults are of the form
|
||||
|
||||
<verb>
|
||||
#ifndef NEW_OPTION
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: linuxemu.sgml,v 1.21 1997-08-12 09:18:05 asami Exp $ -->
|
||||
<!-- $Id: linuxemu.sgml,v 1.22 1997-10-19 13:32:11 jraynard Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<chapt><heading>Linux Emulation<label id="linuxemu"></heading>
|
||||
|
|
@ -51,7 +51,7 @@ options COMPAT_LINUX
|
|||
</verb>
|
||||
</tscreen>
|
||||
If you want to run doom or other applications
|
||||
that need shared memory
|
||||
that need shared memory,
|
||||
also add the following.
|
||||
<tscreen>
|
||||
<verb>
|
||||
|
|
@ -241,7 +241,7 @@ libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29
|
|||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<p>You would need go get all the files from the last column, and
|
||||
<p>You would need to get all the files from the last column, and
|
||||
put them under /compat/linux, with the names in the first column
|
||||
as symbolic links pointing to them. This means you eventually have
|
||||
these files on your FreeBSD system:
|
||||
|
|
@ -291,9 +291,9 @@ that should leave you with:
|
|||
</tscreen>
|
||||
|
||||
<p>Please note that the symbolic link mechanism is <em>only</em>
|
||||
needed for Linux binaries, the FreeBSD runtime linker takes care of
|
||||
looking for matching major revision numbers itself, you do not need to
|
||||
worry about that.
|
||||
needed for Linux binaries. The FreeBSD runtime linker takes care of
|
||||
looking for matching major revision numbers itself and you do not need to
|
||||
worry about it.
|
||||
|
||||
<sect2><heading>Configuring the ld.so -- for FreeBSD 2.2-RELEASE only</heading>
|
||||
|
||||
|
|
@ -329,7 +329,7 @@ version mismatches), and install them under /compat/linux
|
|||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<p>ldconfig and ldd do not necessarily need to be under /compat/linux,
|
||||
<p>ldconfig and ldd do not necessarily need to be under /compat/linux;
|
||||
you can install them elsewhere in the system too. Just make sure they
|
||||
do not conflict with their FreeBSD counterparts. A good idea would be
|
||||
to install them in /usr/local/bin as ldconfig-linux and ldd-linux.
|
||||
|
|
@ -362,17 +362,17 @@ in order for the emulator to find them.
|
|||
|
||||
<p>Ldconfig is statically linked, so it does not need any shared
|
||||
libraries to run. It creates the file /compat/linux/etc/ld.so.cache
|
||||
which contains the names of all the shared libraries. It should rerun
|
||||
which contains the names of all the shared libraries and should be rerun
|
||||
to recreate this file whenever you install additional shared
|
||||
libraries.
|
||||
|
||||
On 2.1-STABLE do not install /compat/linux/etc/ld.so.cache or run
|
||||
ldconfig because in 2.1-STABLE the syscalls are implemented
|
||||
ldconfig; in 2.1-STABLE the syscalls are implemented
|
||||
differently and ldconfig is not needed or used.
|
||||
|
||||
<p>You should now be set up for Linux binaries which only need a
|
||||
shared libc. You can test this by running the Linux ldd on
|
||||
itself. Suppose that you have it installed as ldd-linux, it should
|
||||
itself. Supposing that you have it installed as ldd-linux, it should
|
||||
produce something like:
|
||||
<tscreen>
|
||||
<verb>
|
||||
|
|
@ -390,8 +390,8 @@ ldd(1)) will print a list of shared libraries that the program depends
|
|||
on, in the form majorname (jumpversion) => fullname.
|
||||
|
||||
<p>If it prints "not found" instead of fullname it means that you
|
||||
need an extra library. Which library this is, is shown in majorname,
|
||||
which will be of the form libXXXX.so.N You will need to find a
|
||||
need an extra library. The library needed is shown in majorname
|
||||
and will be of the form libXXXX.so.N. You will need to find a
|
||||
libXXXX.so.N.mm on a Linux ftp site, and install it on your
|
||||
system. The XXXX (name) and N (major revision number) should match;
|
||||
the minor number(s) mm are less important, though it is advised to
|
||||
|
|
@ -425,7 +425,7 @@ complain about the incompatible FreeBSD syntax. You should remove
|
|||
|
||||
<p>Lastly, those who run 2.1-STABLE need to set an the
|
||||
RESOLV_HOST_CONF environment variable so that applications will know
|
||||
how to search the host tables. If you run FreeBSD 2.2-RELEASE can
|
||||
how to search the host tables. If you run FreeBSD 2.2-RELEASE, you can
|
||||
skip this. For the /bin/csh shell use:
|
||||
<tscreen>
|
||||
<verb>
|
||||
|
|
@ -601,12 +601,12 @@ You can do this by invoking:
|
|||
</tscreen>
|
||||
It will ask you to enter your license number and the
|
||||
Wolfram supplied password. If you get them mixed up or
|
||||
for some reason the math.install fails, That is OK,
|
||||
because you can simply edit the file 'mathpass' in this
|
||||
for some reason the math.install fails, that is OK;
|
||||
you can simply edit the file 'mathpass' in this
|
||||
same directory to correct the info manually.
|
||||
|
||||
<p>After getting past the password, math.install will ask
|
||||
you if you accept their canned install defaults, or if
|
||||
you if you accept the install defaults provided, or if
|
||||
you want to use your own. If you are like us and
|
||||
distrust all install programs, you probably want to
|
||||
specify the actual directories. Beware. Although the
|
||||
|
|
@ -635,11 +635,11 @@ go.
|
|||
as the X Front End, and you have to install it separately.
|
||||
To get the X Front End stuff correctly installed, cd
|
||||
into the /usr/local/Mathematica/FrontEnd directory and
|
||||
executed the ./xfe.install shell script. You will have
|
||||
execute the ./xfe.install shell script. You will have
|
||||
to tell it where to put things, but you do not have to
|
||||
create any directories because it uses all the same
|
||||
create any directories because it will use the same
|
||||
directories that had been created for math.install.
|
||||
When it finished, there should be a new shell script in
|
||||
When it finishes, there should be a new shell script in
|
||||
/usr/local/Mathematica/bin called "mathematica".
|
||||
|
||||
<p>Lastly, you need to modify each of the shell scripts that
|
||||
|
|
@ -664,12 +664,12 @@ This tells Mathematica to use the linux version of host.conf. This
|
|||
file has a different syntax from FreeBSD's host.conf, so you will get an
|
||||
error message about /etc/host.conf if you leave this out.
|
||||
|
||||
<p>You might want to also modify your /etc/manpath.config file
|
||||
<p>You might also want to modify your /etc/manpath.config file
|
||||
to read the new man directory, and you may need to edit your
|
||||
~/.cshrc file to add /usr/local/Mathematica/bin
|
||||
to your path.
|
||||
|
||||
<p>That is about all it takes, With this you should be able
|
||||
<p>That is about all it takes. With this you should be able
|
||||
to type "mathematica" and get a really slick looking
|
||||
Mathematica Notebook screen up. Mathematica has included
|
||||
the Motif user interfaces, but it is compiled in statically,
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: memoryuse.sgml,v 1.10 1997-08-12 09:18:06 asami Exp $ -->
|
||||
<!-- $Id: memoryuse.sgml,v 1.11 1997-10-19 13:32:12 jraynard Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>PC Memory Utilization<label id="memoryuse"></heading>
|
||||
|
|
@ -6,7 +6,7 @@
|
|||
<p><em>Contributed by &a.joerg;.<newline>
|
||||
16 Apr 1995.</em>
|
||||
|
||||
<em>A short description of how FreeBSD uses the memory on the i386
|
||||
<em>A short description of how FreeBSD uses memory on the i386
|
||||
platform</em>
|
||||
|
||||
The boot sector will be loaded at <tt>0:0x7c00</tt>, and relocates itself
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: policies.sgml,v 1.15 1997-08-12 09:18:10 asami Exp $ -->
|
||||
<!-- $Id: policies.sgml,v 1.16 1997-10-19 13:32:12 jraynard Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<chapt><heading>Source Tree Guidelines and Policies
|
||||
|
|
@ -92,8 +92,8 @@ produce and install the "tclsh" program and its associated man-pages
|
|||
using the standard bsd.prog.mk rules.
|
||||
|
||||
<p><verb>src/tools/tools/tcl_bmake</verb> contains a couple of shell-scripts that can be of help
|
||||
when the tcl software needs updated, these are not part of the
|
||||
build or installed software.
|
||||
when the tcl software needs updating. These are not part of the
|
||||
built or installed software.
|
||||
|
||||
<p>The important thing here is that the "src/contrib/tcl" directory
|
||||
is created according to the rules: It is supposed to contain the
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: porting.sgml,v 1.80 1997-10-12 16:53:58 max Exp $ -->
|
||||
<!-- $Id: porting.sgml,v 1.81 1997-10-19 13:32:13 jraynard Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect1><heading>Porting an existing piece of free software<label id="porting"></heading>
|
||||
|
|
@ -449,7 +449,7 @@ ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming/
|
|||
<tscreen><verb>
|
||||
ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/LOCAL_PORTS/
|
||||
</verb></tscreen>
|
||||
as the last resort. Please refer to this localation as
|
||||
as the last resort. Please refer to this location as
|
||||
<tt>${MASTER_SITE_LOCAL}</tt>. Send mail to the &a.ports
|
||||
if you are not sure what to do.
|
||||
|
||||
|
|
@ -501,7 +501,7 @@ ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/LOCAL_PORTS/
|
|||
where they will be automatically applied. All patches
|
||||
should be relative to <tt>${WRKSRC}</tt> (generally
|
||||
the directory your port's tarball unpacks itself into, that
|
||||
being where the make is done). To make fixes and upgrades
|
||||
being where the build is done). To make fixes and upgrades
|
||||
easier you should avoid having more than one patch fix the
|
||||
same file (e.g., patch-aa and patch-ab both changing
|
||||
<tt>${WRKSRC}</tt>/foobar.c).
|
||||
|
|
@ -1432,7 +1432,7 @@ MAN8= baz.8
|
|||
pathname of <tt>less</tt>, use the compiler flag:
|
||||
<verb>-DPAGER=\"${PREFIX}/bin/less\"</verb> or
|
||||
<verb>-DPAGER=\"${LOCALBASE}/bin/less\"</verb> if this is an
|
||||
X port, instead of <verb>-DPAGER=\"/usr/local/bin/less\"</verb>.
|
||||
X port, instead of <verb>-DPAGER=\"/usr/local/bin/less\".</verb>
|
||||
This way it will have a better chance of working if the system
|
||||
administrator has moved the whole `/usr/local' tree somewhere
|
||||
else.
|
||||
|
|
@ -1661,7 +1661,7 @@ msql:*:80:249:mSQL-2 pseudo-user:/var/db/msqldb:/bin/sh
|
|||
papersize and font units.
|
||||
|
||||
<item>The version string should be a period-separated list of
|
||||
integers and single lowercase alphabets. The only exception
|
||||
integers and single lowercase alphabetics. The only exception
|
||||
is the string `pl' (meaning `patchlevel'), which can be used
|
||||
<em>only</em> when there are no major and minor version
|
||||
numbers in the software.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Id: stable.sgml,v 1.14 1997-08-12 09:18:26 asami Exp $ -->
|
||||
<!-- $Id: stable.sgml,v 1.15 1997-10-19 13:32:14 jraynard Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
|
||||
|
|
@ -10,7 +10,7 @@
|
|||
|
||||
THE FREEBSD STABLE POLICY
|
||||
|
||||
Last updated: $Date: 1997-08-12 09:18:26 $
|
||||
Last updated: $Date: 1997-10-19 13:32:14 $
|
||||
|
||||
This document attempts to explain the rationale behind
|
||||
FreeBSD-stable, what you should expect should you decide to run it,
|
||||
|
|
@ -49,7 +49,7 @@ next section).
|
|||
keep you informed of build-dependencies that may appear in
|
||||
<em>stable</em> or any other issues requiring special attention.
|
||||
Developers will also make announcements in this mailing list when
|
||||
they are contemplating some contraversal fix or update, giving
|
||||
they are contemplating some controversial fix or update, giving
|
||||
the users a chance to respond if they have any issues to raise concerning
|
||||
the proposed change.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue