svn commit: r40999 - head/en_US.ISO8859-1/books/handbook/kernelconfig
Benjamin Kaduk
kaduk at MIT.EDU
Tue Feb 19 05:48:04 UTC 2013
On Sun, 17 Feb 2013, Dru Lavigne wrote:
> Modified: head/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.xml
> ==============================================================================
> --- head/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.xml Sun Feb 17 17:28:26 2013 (r40998)
> +++ head/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.xml Sun Feb 17 17:41:05 2013 (r40999)
> @@ -281,78 +261,66 @@ following line in &man.loader.conf.5;:
> to build the kernel.</para>
> </note>
>
> + <para>The kernel build is located at <filename
> + class="directory">/usr/src/sys</filename>. It contains a
The kernel build is at /usr/obj/usr/src/sys/. This should probably refer
to the kernel source.
> + number of subdirectories representing different parts of the
> + kernel. These include <filename
> + class="directory"><replaceable>arch</replaceable>/conf</filename>,
> + which contains the kernel configuration file, and
> + <filename class="directory">compile</filename>, which is the
> + staging area where the kernel will be built.
Oof, this is really out of date, probably from 4.X or worse. (The above
is probably a symptom of the same problem.)
There is no /usr/src/sys/compile directory on modern systems, I think this
is a legacy from manually invoking config(8). Of course, I can't easily
check, as Eitan has removed all of the bits from the manual for the "old"
method of building a kernel. The man page does seem to support this,
though.
Probably someone should audit the hierarchy described here against a
recent kernel build.
> + <replaceable>arch</replaceable> contains subdirectories for each
> + supported architecture: <filename
> + class="directory">i386</filename>, <filename
> + class="directory">amd64</filename>, <filename
> + class="directory">ia64</filename>, <filename
> + class="directory">powerpc</filename>, <filename
> + class="directory">sparc64</filename>, and <filename
> + class="directory">pc98</filename>. Everything inside a
> particular architecture's directory deals with that architecture
> - only; the rest of the code is machine independent code common
> - to all platforms to which &os; could potentially be ported.
> - Notice the logical organization of the directory structure,
> - with each supported device, file system, and option in its
> - own subdirectory.</para>
> -
> - <para>The examples in this chapter assume that you are using
> - the i386 architecture. If your system has a different
> - architecture you need to change the path names
> - accordingly.</para>
> + only and the rest of the code is machine independent code common
> + to all platforms. Notice the logical organization of the
> + directory structure, with each supported device, file system,
> + and option in its own subdirectory.</para>
> +
> + <para>The examples in this chapter assume the i386 architecture.
> + If the system has a different architecture, change the path
> + names accordingly.</para>
If we had infinite time, amd64 might be more representative than i386
these days. That said, we have better things to do with our time.
> <note>
> - <para>If the directory <filename>/usr/src/</filename> does not
> - exist on your system (or if it is empty), then the sources
> - have not been installed. The easiest way to install the full
> - source is to use &man.csup.1; as described in <xref
> - linkend="synching"/>. You should also create a symlink to
> + <para>If <filename class="directory">/usr/src/</filename> does
> + not exist or it is empty, source has not been installed. The
> + easiest way to install source is to use
> + <application>svn</application> as described in <link
> + linkend="svn"></link>. One should also create a symlink to
I don't agree with using just "source" to describe the system sources; it
seems too ambiguous.
> <filename class="directory">/usr/src/sys/</filename>:</para>
>
> <screen>&prompt.root; <userinput>ln -s /usr/src/sys /sys</userinput></screen>
> </note>
>
> @@ -429,52 +391,49 @@ following line in &man.loader.conf.5;:
>
> <programlisting>MODULES_OVERRIDE = linux acpi sound/sound sound/driver/ds1 ntfs</programlisting>
>
> - <para>This variable sets up a list of modules to build instead
> - of all of them.</para>
> + <para>This variable specifies the list of modules to build
> + instead the default of building of all of them.</para>
This sentence feels a bit awkward ("the default of building of all of
them"); I'd prefer "the list of modules to build. The default is to build
all modules." or something similar.
> @@ -600,37 +550,29 @@ cpu I686_CPU</programlisting>
>
> <programlisting>ident GENERIC</programlisting>
>
> - <para>This is the identification of the kernel. You should change
> - this to whatever you named your kernel,
> - i.e., <literal><replaceable>MYKERNEL</replaceable></literal>
> - if you have followed the instructions of the previous examples.
> - The value you put in the <literal>ident</literal> string will
> - print when you boot up the kernel, so it is useful to give the
> - new kernel a different name if you want to keep it separate
> - from your usual kernel (e.g., you want to build an experimental
> - kernel).</para>
> + <para>This is the identification of the kernel. Change
> + this to the new kernel name, such as
> + <literal><replaceable>MYKERNEL</replaceable></literal>.
> + The value in the <literal>ident</literal> string will
> + print when the kernel boots.</para>
I prefer "be printed" to "print".
> <!-- XXX: Add a comment here that explains when compiling hints into
> the kernel is a good idea and why. -->
>
> <programlisting>makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols</programlisting>
>
> - <para>The normal build process of &os; includes
> - debugging information when building the kernel with the
> - <option>-g</option> option, which enables debugging
> - information when passed to &man.gcc.1;.</para>
> + <para>This option enables debugging information when passed to
> + &man.gcc.1;.</para>
clang handles -g just fine. Maybe we should link to cc(1) which I think
changes between gcc and clang with WITH_CLANG_IS_CC?
> <programlisting>options SCHED_ULE # ULE scheduler</programlisting>
>
> @@ -638,17 +580,14 @@ cpu I686_CPU</programlisting>
>
> <programlisting>options PREEMPTION # Enable kernel thread preemption</programlisting>
>
> - <para>Allows threads that are in the kernel to be preempted
> - by higher priority threads. It helps with interactivity and
> - allows interrupt threads to run sooner rather than
> - waiting.</para>
> + <para>Allows kernel threads to be preempted by higher priority
> + threads. This helps with interactivity and allows interrupt
> + threads to run sooner rather than waiting.</para>
>
> <programlisting>options INET # InterNETworking</programlisting>
>
> - <para>Networking support. Leave this in, even if you do not
> - plan to be connected to a network. Most programs require at
> - least loopback networking (i.e., making network connections
> - within your PC), so this is essentially mandatory.</para>
> + <para>Networking support. This is mandatory as most programs
> + require at least loopback networking.</para>
>
> <programlisting>options INET6 # IPv6 communications protocols</programlisting>
bz et al may be a bit miffed that INET loopback is mandatory, given their
work on INET6-only systems. I don't know that there's a better way to
phrase things than what you have, though.
> @@ -657,40 +596,38 @@ cpu I686_CPU</programlisting>
> <programlisting>options FFS # Berkeley Fast Filesystem</programlisting>
>
> <para>This is the basic hard drive file system. Leave it in if
> - you boot from the hard disk.</para>
> + the system boots from the hard disk.</para>
Probably "a hard disk", here.
>
> <programlisting>options SOFTUPDATES # Enable FFS Soft Updates support</programlisting>
>
> - <para>This option enables Soft Updates in the kernel, this will
> - help speed up write access on the disks. Even when this
> + <para>This option enables Soft Updates in the kernel which helps
> + to speed up write access on the disks. Even when this
> functionality is provided by the kernel, it must be turned on
> - for specific disks. Review the output from &man.mount.8; to
> - see if Soft Updates is enabled for your system disks. If you
> - do not see the <literal>soft-updates</literal> option then you
> - will need to activate it using the &man.tunefs.8; (for existing
> - file systems) or &man.newfs.8; (for new file systems)
> - commands.</para>
> + for specific disks. Review the output so &man.mount.8; to
SU is per-file-system, not per disk. I'm not sure where the bug in the
original came from, but we can fix it here.
> + determine if Soft Updates is enabled. If the
> + <literal>soft-updates</literal> option is not in the output, it
> + can be activated using &man.tunefs.8; for existing file systems
> + or &man.newfs.8; for new file systems.</para>
>
> @@ -709,9 +646,10 @@ cpu I686_CPU</programlisting>
> options NFSSERVER # Network Filesystem Server
> options NFS_ROOT # NFS usable as /, requires NFSCLIENT</programlisting>
>
> - <para>The network file system. Unless you plan to mount
> - partitions from a &unix; file server over TCP/IP, you can
> - comment these out.</para>
> + <para>The network file system (<acronym>NFS</acronym>). These
> + lines can be commented unless the system needs to mount
> + partitions from a <acronym>NFS</acronym> file server over
> + TCP/IP.</para>
NFS works just fine over UDP/IP as well. I don't think there's need to
include "over TCP/IP" at all.
>
> <indexterm>
> <primary>kernel options</primary>
> @@ -719,34 +657,32 @@ options NFS_ROOT # NFS
> <programlisting>options PROCFS # Process filesystem (requires PSEUDOFS)</programlisting>
>
> <para>The process file system. This is a <quote>pretend</quote>
I think "pseudo file system" is more of the term of art.
> - file system mounted on <filename>/proc</filename> which allows
> - programs like &man.ps.1; to give you more information on what
> - processes are running. Use of <literal>PROCFS</literal>
> - is not required under most circumstances, as most
> - debugging and monitoring tools have been adapted to run without
> - <literal>PROCFS</literal>: installs will not mount this file
> - system by default.</para>
> + file system mounted on <filename
> + class="directory">/proc</filename> which allows some programs
> + to provide more information on what processes are running. Use
> + of <literal>PROCFS</literal> is not required under most
> + circumstances, as most debugging and monitoring tools have been
> + adapted to run without <literal>PROCFS</literal>. The default
> + installation will not mount this file system by default.</para>
Two uses of "default" in the same sentence; I would probably change the
first to "standard".
>
> <programlisting>options PSEUDOFS # Pseudo-filesystem framework</programlisting>
>
> @@ -757,51 +693,49 @@ options NFS_ROOT # NFS
>
> <para>Adds support for <ulink
> url="http://en.wikipedia.org/wiki/GUID_Partition_Table">GUID
> - Partition Tables</ulink>. GPT provides the ability to have a
> - large number of partitions per disk, 128 in the standard
> - configuration.</para>
> + Partition Tables</ulink> (<acronym>GPT</acronym>. GPT
close paren?
> + provides the ability to have a large number of partitions per
> + disk, 128 in the standard configuration.</para>
>
[...]
>
> <programlisting>options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI</programlisting>
>
> <para>This causes the kernel to pause for 5 seconds before probing
> - each SCSI device in your system. If you only have IDE hard
> - drives, you can ignore this, otherwise you can try to lower
> - this number, to speed up booting. Of course, if you do this
> - and &os; has trouble recognizing your SCSI devices, you will
> - have to raise it again.</para>
> + each SCSI device in the system. If the system only has IDE hard
> + drives, ignore this or lower the number to speed up booting.
> + However, if &os; has trouble recognizing the SCSI devices, the
Spurious "the"?
> + number will have to be raised again.</para>
Maybe s/number/timeout/?
-Ben
>
> *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
>
More information about the svn-doc-head
mailing list