From owner-svn-src-all@FreeBSD.ORG Thu Jan 14 21:06:55 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F396106566C; Thu, 14 Jan 2010 21:06:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id CF2218FC14; Thu, 14 Jan 2010 21:06:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o0EKwWth014817; Thu, 14 Jan 2010 13:58:32 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 14 Jan 2010 13:59:30 -0700 (MST) Message-Id: <20100114.135930.80200584442733547.imp@bsdimp.com> To: rwatson@freebsd.org From: "M. Warner Losh" In-Reply-To: <86625798-F339-4863-8F97-63B5232A6CF7@freebsd.org> References: <20100114.105622.457034909117828677.imp@bsdimp.com> <4B4F7810.2080003@FreeBSD.org> <86625798-F339-4863-8F97-63B5232A6CF7@freebsd.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, dougb@freebsd.org, src-committers@freebsd.org, freebsd-arch@freebsd.org Subject: Re: INCLUDE_CONFIG_FILE in GENERIC X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 21:06:55 -0000 In message: <86625798-F339-4863-8F97-63B5232A6CF7@freebsd.org> "Robert N. M. Watson" writes: : : On 14 Jan 2010, at 20:01, Doug Barton wrote: : : > FWIW, I actually think this makes it worse, not better. The : > INCLUDE_CONFIG_FILE option should include everything needed to recreate : > the kernel. If it doesn't, it's worse than worthless, it leads to a : > false sense of security which makes it dangerous. I wasn't actually : > aware that if you do the config -C trick that you'll get ONLY the one : > file, not everything. : : (...more irritated words stripped like the comments in a config file...) : : I agree. I see two kinds of users: : : - Desktop/server users who want their system to work without any : special tuning or magic, and likely feel the comments they put in : configuration files are important : - Users who care a about a few hundred bytes of comments due to the : nature of their special embedded hardware target environment : : As such, I see a reasonable "default" -- i.e., i386/amd64 GENERIC -- : be to fully preserve the configuration and its comments. For the : embedded and appliance crowds, I definitely want them to be able to : fully exclude the configuration (by not including the option). I : don't see a lot of merit to supporting stripping the comments, but : if someone wants that special case, I'm OK with supporting it, but I : think it's an unuseful default for the desktop/server platforms. I think you are confusing two different things. The embedded folks omit this entirely. That's not the issue at all here. Space is not the concern. We're putting it into GENERIC. Why are there two ways? Because there are two points in the process one can squirt the data out of config. Let me explain (sorry for the length, but it is necessary to clear up the confusion): The first way is "preserve the FILE the user used to create the kernel" on the assumption that the FILE is what is important. This will preserve the comments, but assumes that every single included file from that file is recoverable in a trivial manner (eg, from cvs, svn, p4, release ISOs, etc). This model works well for the casual user. In this model, we're therefore able to preserve the kernel config by copying the file, verbatim, into the kernel. I think this is the model that best fits most user's needs, since they EITHER take GENERIC and hack on it (in which case we preserve all that), OR they include GENERIC and opt in/out of things based on that default. Either way, this is the best way for users of releases to preserve the data they need to recreate the kernel without losing data that's important to the user, but not config (comments, spacing, order, etc). The other way of preserving the config file is to say "I want EVERYTHING applied, and I want a copy of that!" To get that, you have to walk through config's internal data structures. By the time we get to *THAT* point in the processing, comments are but a distant memory. Those are discarded early, along with the variations in spacing, blank lines. By this point in the process, even the original ordering is long gone, as is the origin of each of the remaining items in config's internal data structures. However, the resulting config file that we generate here is GUARANTEED to recreate the same kernel from the same sources modulo any silly time/date/path stuff we encode. There's a class of user that would find this comforting, or essential, since they may have multiple include files that they control, etc. In addition, since the config is presented as a sysctl, users could query it to see if the kernel had certain things compiled in or not. For some applications, this is important to know, even though other methods usually work better. So it isn't that there's an option to just strip comments or not strip comments, these two different options save data at two radically different points in the process. Both have their pros and cons. If space isn't an issue, we could save BOTH. That would be a bigger patch, since we'd have to alter config to extract both kinds of data. All I did was to move the -C option from an obscure src.conf variable to be a full-fledged kernel option, leaving the rest of the infrastructure intact. The advantage is that we cover both bases and could export both views as a sysctl (right now we overload the two different views with one sysctl). Heck, we could save the whole src/sys tree as a tarball in a separate non-loadable ELF section if people that that was useful. This could be implemented entirely in the *.mk files, however, without the need to modify config(8). Warner