From owner-freebsd-arch@FreeBSD.ORG Thu Jan 14 07:32:25 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B10C1106568B; Thu, 14 Jan 2010 07:32:24 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id E6BF68FC15; Thu, 14 Jan 2010 07:32:22 +0000 (UTC) Received: by fxm27 with SMTP id 27so525861fxm.3 for ; Wed, 13 Jan 2010 23:32:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=K6iODhB5ZuLwETp20LHwGnw35ZM9QS3R91jRnUXXmgk=; b=epsBugqNL+Sk/ijC7DGSa1gfKv0mPv/AdBkFrzd17zOtsgtisyNOp47125Niuxj0vY 4p8yLGx6/f/4X6d6c7vzacGe1rh38pU/n0drpp5gma9TIR2Bif/18pFZ68OHyPwh1TsC LeiKECV+8FqveyzoZjjhe+F8ZRBxWl+DmC1CY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=ipfNN8OV8QVuShDA+a43UeYkAPRUmKyvpeU0V50GUEn70JsAHR2sQCQIJc2S0FUB7i jJFXm7RvUI03uzfEDABfEssGKbWKs6WYsogij2vPlOYIe6EFZONkYD4q9/aKR3yQu9cg y/EVA7wx4d2cqWzOYIYe/nDi3qPHucHWFsdIw= Received: by 10.223.76.65 with SMTP id b1mr450497fak.5.1263452935066; Wed, 13 Jan 2010 23:08:55 -0800 (PST) Received: from mbp-gige.totalterror.net (93-152-151-19.ddns.onlinedirect.bg [93.152.151.19]) by mx.google.com with ESMTPS id 18sm457098fks.4.2010.01.13.23.08.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 13 Jan 2010 23:08:53 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: <20100113.150435.650865766805848595.imp@bsdimp.com> Date: Thu, 14 Jan 2010 09:08:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201001131515.08602.jhb@freebsd.org> <4B4E2ECA.90905@FreeBSD.org> <201001131633.09669.jhb@freebsd.org> <20100113.150435.650865766805848595.imp@bsdimp.com> To: M. Warner Losh X-Mailer: Apple Mail (2.1077) Cc: dougb@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, freebsd-arch@freebsd.org, svn-src-head@freebsd.org Subject: Re: INCLUDE_CONFIG_FILE in GENERIC X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 07:32:25 -0000 On 14 Jan, 2010, at 24:04 , M. Warner Losh wrote: > In message: <201001131633.09669.jhb@freebsd.org> > John Baldwin writes: > : On Wednesday 13 January 2010 3:36:26 pm Doug Barton wrote: > : > On 1/13/2010 12:15 PM, John Baldwin wrote: > : > > On Wednesday 13 January 2010 1:48:38 pm Doug Barton wrote: > : > >> To address the other responses, Tom, sorry, your suggested text = doesn't > : > >> address my concern. John, I don't think that users would = somehow > : > >> magically know to look in NOTES for more information about an = option > : > >> that is already in GENERIC. > : > >=20 > : > > You really think users do not already know to look in manpages = or NOTES to=20 > : > > find out more details about kernel options?=20 > : >=20 > : > That's not what I said. > :=20 > : > : I don't think that users would [..] know to look in NOTES for more = information=20 > : about an option that is [...] in GENERIC. > : > :=20 > : That seems really straight forward to me, or my English isn't good. = I do=20 > : think users "would know to look in NOTES for more information about = an option=20 > : that is in GENERIC". >=20 > Agreed. That's why I did what I did: I conformed to the usual = practice. >=20 > : > > Put=20 > : > > another way, what makes 'INCLUDE_CONFIG_FILE' sufficiently = special that it=20 > : > > deserves special treatment relative to other kernel options? > : >=20 > : > Because the default behavior (not including the actual file) for = the > : > option is contrary to user' reasonable expectation of how the = option > : > should work .... and now I'm repeating myself. > :=20 > : I think a better change would be to just change the default behavior = of=20 > : config(8) to do the reasonable thing. >=20 > -C should be the default, and we should invent a new > '--smaller-saved-config' option. >=20 > : > Seriously, don't you have anything better to do than argue against > : > including a comment in a config file? I know I do. What is the > : > overwhelming horror that will arise here if there are more = comments > : > GENERIC than you deem to be absolutely necessary? > :=20 > : What is the overwhelming horror about keeping a file readable and = allowing=20 > : users to find extended documentation for INCLUDE_CONFIG_FILE in the = same place=20 > : that they find extended documentation about every other kernel = option? >=20 > Yes. That's why I did what I did: to keep things readable. >=20 > : > And yes, I read the part of your message that I snipped about "why = do we > : > have these documents if users don't read them?" The answer is, = that's > : > why I'm suggesting a comment that tells users what man page to = read. > :=20 > : I think adding comments that merely redirect the users to further=20 > : documentation only serves to obfuscate. Left unchecked this = approach will=20 > : render files such as GENERIC with a very low signal-to-noise ratio = making it=20 > : harder to parse in a "big picture" way. >=20 > Yes. >=20 > Basically, I'm annoyed too: Our users aren't idiots, and we shouldn't > be treating them as such at every turn. If there are surprises with > how INCLUDE_CONFIG_FILE behaves, we should work to make it better, not > paper over it with a comment. >=20 > Warner Hello, I just want to add a user's point of view : To me INCLUDE_CONFIG_FILE sounds like the whole config file will be included, not just the output after preprocessing. So I was thinking about something like two different options, one "INCLUDE_CONFIG_FILE" which includes the whole file with comments, and the other to be just "INCLUDE_CONFIG". I think these would be pretty self-explanatory. Yes, it adds another kernel option, but having options to kernel options looks even more cryptic :) -- Regards, Niki=