Date: Sun, 7 Jul 2002 23:02:46 -0400 From: Chris Pepper <pepper@reppep.com> To: Giorgos Keramidas <keramida@FreeBSD.org> Cc: freebsd-doc@FreeBSD.org Subject: Re: docs/39824: Various tweaks for doc/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.sgml; corresponding comment clarification for GENERIC Message-ID: <a05200101b94e93ff99e7@[64.81.19.109]> In-Reply-To: <200207030020.g630K4GZ037338@freefall.freebsd.org> References: <200207030020.g630K4GZ037338@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 5:20 PM -0700 2002/07/02, Giorgos Keramidas wrote:
>The following reply was made to PR docs/39824; it has been noted by GNATS.
>
>From: Giorgos Keramidas <keramida@FreeBSD.org>
>To: Chris Pepper <pepper@rockefeller.edu>
>Cc: bug-followup@FreeBSD.org
>Subject: Re: docs/39824: Various tweaks for
>doc/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.sgml;
>corresponding comment clarification for GENERIC
>Date: Wed, 3 Jul 2002 03:11:36 +0300
>
> On 2002-06-24 23:45 +0000, Chris Pepper wrote:
> > Index: chapter.sgml
> > ===================================================================
> > RCS file:
>/home/ncvs/doc/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.sgml,v
> > retrieving revision 1.76
>
> See comments inline. I have refrained from commenting on large parts
> of this patch. Where there have not been any comments appended to the
> patch text, you may safely assume my approval. So, here it is:
>
> > @@ -120,7 +120,7 @@
> >
> > <listitem>
> > <para>Additional hardware support. A custom kernel allows you to
> > - add in support for devices such as sound cards, which are not
> > + add in support for devices such as sound cards which are not
> > present in the <literal>GENERIC</literal> kernel.</para>
> > </listitem>
> > </itemizedlist>
>
> Actually, wouldn't this be more correct by converting the "such as..."
> part in a parenthetical expression of some sort & enclosing it in commas?
>
> <para>Additional hardware support. A custom kernel allows you to
> - add in support for devices such as sound cards, which are not
> + add in support for devices, such as sound cards, which are not
>
> In this version, "which" clearly refers to "devices".
> What do you think?
If you're going to rework it that much, I'd make it "devices
which are not present in the default kernel, such as sound cards or
the IPFW firewall".
Actually, though, it should be rewritten to mention that
sound drivers and other kernel functions can be loaded via kldload
(see kern/39814 & Message-ID:
<20020625194229.GA1289@fonix.adamsfamily.xx>). I'm not clear on the
details yet, but kernel rebuilds are no longer a requirement for this
purpose. The problematic section is likely to get fixed or eliminated
as a side-effect.
> > + <para>If you <link linkend="cutting-edge">update your
>FreeBSD source</link>, be sure to check the file
> > + <filename>/usr/src/UPDATING</filename>.
> > + This file mentions important issues you should be aware
>of when working with updated FreeBSD source code.
><filename>/usr/src/UPDATING</filename> always tracks
> > + your version of the FreeBSD source, and is therefore
>more up to date
> > + for your system than the handbook.</para>
>
> Apart from a few terrible wrapping issues,
> the new text looks great :)
Well, do you want me never to wrap, or to wrap when it gets
over 80col, or what?
> > if you have them enabled. If you do not see the
>soft-updates option then
> > - you will need to activate it using the &man.tunefs.8; or
>&man.newfs.8;
> > + you may activate it using &man.tunefs.8; or &man.newfs.8;
> > for new filesystems.</para>
>
> Hmmm, softupdates can be activated for existing filesystems too. I
> recently helped a guy on IRC to hack his /etc/rc script and enable
> softupdates for all his filesystems, while logged in through ssh to a
> collocated FreeBSD machine. This part needs a bit more clarification.
Sounds good, but I don't know enough to clarify. Sounds like
you do, though. ;)
> > <para>Allow users to grab the console, which is useful for X users.
> > For example, you can create a console xterm by typing <command>xterm
> > -C</command>, which will display any <command>write</command>,
> > - <command>talk</command>, and any other messages you receive, as well
> > + <command>talk</command>, and other messages you receive, as well
> > as any console messages sent by the kernel.</para>
>
> Not sure if this is an improvement.
> "foo ... and bar, as well as baz" looks funny.
How about:
-C</command>, which will display any messages sent to you
with <command>write</command> or <command>talk</command>, as well
as any console messages sent by the kernel.</para>
> > values for these lines. Some video cards (notably those based on
> > - S3 chips) use IO addresses in the form of
> > + S3 chipsets) use IO addresses in the form of
>
> Well, this change seems a bit gratuitous. But I'll let the majority
> of the freebsd-doc English speaking people decide :)
Whatever. I think it's better, but not important.
> > - <para>This is the ISA-bus parallel port interface.</para>
> > + <para>This is the ISA bus parallel port interface.</para>
>
> is this really necessary too?
I've never seen 'ISA-bus' before, but also not important.
> > Some additional comments on this chapter:
> >
> > >If you have not upgraded your source tree in any way (you have not
> > >run CVSup, CTM, or used anoncvs), then you should use the config,
> > >make depend, make, make install sequence.
> >
> > This paragraph appears to assume that should use the old kernel
> > build procedure, rather than the new procedure. I'm not sure what
> > the equivalent is for the new style, or if this para serves any
> > purpose (after the earlier section explaining when to use old vs.
> > new procedures).
>
> No. It means exactly what it says. Although it needs a bit more
> detail. If you haven't CVSup'ed your sources, and you still have the
> /usr/obj files from your last kernel build around, you can safely use
> the old way to change kernel options. If the old /usr/obj files are
> around and you do NOT ommit the 'depend' step, but DO ommit the
> 'clean' step, you may save some cycles by avoiding a full kernel
> compile. Only the affected parts of the kernel should be rebuilt.
Right. In this situation (which isn't described very
clearly), you're suggesting the old procedure. I don't see its value
over the new procedure, and thought you'd be encouraging people to
use the new procedure. When I read it (and the other bits about
kernel rebuilds), I got the impression the 'new' procedure was still
experimental, which I don't believe is the current impression that
should be conveyed. If it bugs you, please just ignore.
Thanks,
Chris
--
Chris Pepper: <http://www.reppep.com/~pepper/>;
Rockefeller University: <http://www.rockefeller.edu/>;
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a05200101b94e93ff99e7>