From owner-freebsd-doc Sun Jul 7 20: 4:57 2002 Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C5F737B400; Sun, 7 Jul 2002 20:04:52 -0700 (PDT) Received: from mail.reppep.com (www.reppep.com [64.81.19.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6640243E58; Sun, 7 Jul 2002 20:04:51 -0700 (PDT) (envelope-from pepper@reppep.com) Received: from [64.81.19.109] (g4.reppep.com [64.81.19.109]) by mail.reppep.com (Postfix) with ESMTP id 9A32317B8C; Sun, 7 Jul 2002 22:09:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: pepper@mail.reppep.com Message-Id: In-Reply-To: <200207030020.g630K4GZ037338@freefall.freebsd.org> References: <200207030020.g630K4GZ037338@freefall.freebsd.org> Date: Sun, 7 Jul 2002 23:02:46 -0400 To: Giorgos Keramidas From: Chris Pepper Subject: Re: docs/39824: Various tweaks for doc/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.sgml; corresponding comment clarification for GENERIC Cc: freebsd-doc@FreeBSD.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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 >To: Chris Pepper >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 @@ > > > > > > 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 GENERIC kernel. > > > > > > Actually, wouldn't this be more correct by converting the "such as..." > part in a parenthetical expression of some sort & enclosing it in commas? > > 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. > > + If you update your >FreeBSD source, be sure to check the file > > + /usr/src/UPDATING. > > + This file mentions important issues you should be aware >of when working with updated FreeBSD source code. >/usr/src/UPDATING always tracks > > + your version of the FreeBSD source, and is therefore >more up to date > > + for your system than the handbook. > > 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. > > 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. ;) > > Allow users to grab the console, which is useful for X users. > > For example, you can create a console xterm by typing xterm > > -C, which will display any write, > > - talk, and any other messages you receive, as well > > + talk, and other messages you receive, as well > > as any console messages sent by the kernel. > > Not sure if this is an improvement. > "foo ... and bar, as well as baz" looks funny. How about: -C, which will display any messages sent to you with write or talk, as well as any console messages sent by the kernel. > > 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. > > - This is the ISA-bus parallel port interface. > > + This is the ISA bus parallel port interface. > > 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: Rockefeller University: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message