Improved wording of keymap related paragraphs (bug 741)

git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@3818 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

chapter01/changelog.xml

@@ -76,6 +76,10 @@ first a summary, then a detailed log.</para>
 </itemizedlist>
 </listitem>
 
+<listitem><para>June 19, 2004 [matt]: chapter07 - console &amp; chapter 08 -
+kernel.  Improved wording and re-introduced the option for compiling the keymap
+directly into the kernel.</para></listitem>
+
 <listitem><para>June 19, 2004 [matt]: chapter06 - e2fsprogs, brought
 instructions inline with upstream recommendations.</para></listitem>
 

chapter07/console.xml

@@ -91,17 +91,18 @@ after the main keymap:</para>
 KEYMAP_CORRECTION="/etc/kbd/bs-sends-del"
 EOF</userinput></screen>
 
-<para>If you decided to
-compile your keymap directly into the kernel later on in <xref
-linkend="chapter-bootable"/> instead of setting it every time from the
-<command>console</command> bootscript, then you don't need to run the
-<command>loadkeys</command> program. Since the kernel will set up the keymap,
-you can omit the KEYMAP variable from the
-<filename>/etc/sysconfig/console</filename>
-configuration file. If you wish,
-you can still have it, this isn't going to hurt you. Keeping it could even
-be beneficial, in case you run a lot of different kernels and can't be sure
-that the keymap is compiled into every one of them.</para>
+<para>If you want to compile your keymap directly into the kernel instead of
+setting it every time from the <command>console</command> bootscript, then
+instructions are given in <xref linkend="ch-bootable-kernel"/>.  Doing this
+ensures that your keyboard will always work as expected, even when you boot into
+maintenance mode (by passing `init=/bin/sh' to the kernel), as in that
+situation, the <command>console</command> bootscript won't be run.</para>
+
+<para>Since the kernel will set up the keymap, you can omit the KEYMAP variable
+from the <filename>/etc/sysconfig/console</filename> configuration file. If you
+wish, you can still have it, this isn't going to hurt you. Keeping it could even
+be beneficial, in case you run a lot of different kernels and can't be sure that
+the keymap is compiled into every one of them.</para>
 
 </sect1>
 

chapter08/kernel.xml

@@ -43,16 +43,26 @@ recommends that this command be issued prior to <emphasis>each</emphasis>
 kernel compilation. You shouldn't rely on the source tree being clean after
 un-tarring.</para>
 
-<para>Also, assure that the kernel does not attempt to pass hotplugging events
+<para>Also, ensure that the kernel does not attempt to pass hotplugging events
 to userspace until userspace specifies that it is ready:</para>
 
 <screen><userinput>sed -i 's@/sbin/hotplug@/bin/true@' kernel/kmod.c</userinput></screen>
 
+<para>If, in <xref linkend="ch-scripts-console"/>, you decided you want
+to compile the keymap into the kernel, issue the command below:</para>
+
+<screen><userinput>loadkeys -m
+/usr/share/kbd/keymaps/<replaceable>[path to  keymap]</replaceable> &gt; \
+    <replaceable>[unpacked sources dir]</replaceable>/linux-&linux-version;/drivers/char/defkeymap.c</userinput></screen>
+
+<para>For example, if you have a Dutch keyboard, you would use
+<filename>/usr/share/kbd/keymaps/i386/qwerty/nl.map.gz</filename>.</para>
+
 <para>Configure the kernel via a menu-driven interface:</para>
 
 <screen><userinput>make menuconfig</userinput></screen>
 
-<para><command>make oldconfig</command> may be more appropriate in some
+<para><userinput>make oldconfig</userinput> may be more appropriate in some
 situations. See the <filename>README</filename> file for more
 information.</para>
 
@@ -69,8 +79,8 @@ scratch.</para>
 the <quote>File systems</quote> menu and is normally enabled by default.</para>
 
 <para>LFS bootscripts make the assumption that you either compile
-both <quote>Support for Host-side USB</quote> and
-<quote>USB device filesystem</quote> directly into the kernel, or don't compile them at
+both "Support for Host-side USB" and
+"USB device filesystem" directly into the kernel, or don't compile them at
 all. Bootscripts will not work properly if it is a module (usbcore.ko).</para>
 
 <note><para>NPTL requires the kernel to be compiled with GCC 3.x, in this case
@@ -120,7 +130,7 @@ isn't worth the trouble, but if you're really pressed for space, then have a loo
 <ulink url="http://www.linux-mips.org/archives/linux-mips/2002-04/msg00031.html"/>.</para>
 
 <para>Kernel compilation has finished but more steps are required to complete
-the installation. Some files need to be copied to the <filename class="directory">/boot</filename>
+the installation. Some files need to be copied to the <filename>/boot</filename>
 directory.</para>
 
 <para>The path to the kernel image may vary depending on the platform you're
@@ -154,7 +164,7 @@ person would have write access to the kernel source.</para>
 
 <para>If you are going to keep the kernel source tree around, you may want to
 run <userinput>chown -R 0:0</userinput> on the
-<filename class="directory">linux-&linux-version;</filename> directory to ensure all files are
+<filename>linux-&linux-version;</filename> directory to ensure all files are
 owned by user <emphasis>root</emphasis>.</para>
 
 </sect2>
@@ -189,7 +199,7 @@ of running scores of programs seemingly at the same time.</para>
 <indexterm zone="ch-bootable-kernel kernel-headers"><primary sortas="e-kernel-headers">kernel headers</primary></indexterm>
 <para>define the interface to the
 services that the kernel provides. The headers in your system's
-<filename class="directory">include</filename> directory should <emphasis>always</emphasis> be
+<filename>include</filename> directory should <emphasis>always</emphasis> be
 the ones against which Glibc was compiled and should therefore
 <emphasis>not</emphasis> be replaced when upgrading the kernel.</para>
 </listitem>