From owner-svn-src-head@FreeBSD.ORG Fri Jan 15 18:06:14 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 679ED1065670; Fri, 15 Jan 2010 18:06:14 +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 26ACB8FC0A; Fri, 15 Jan 2010 18:06:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o0FI4iCQ034251; Fri, 15 Jan 2010 11:04:44 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 15 Jan 2010 11:05:28 -0700 (MST) Message-Id: <20100115.110528.849557997928257031.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: References: <20100115114822.O63406@delplex.bde.org> <20100115174711.GF1990@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: dougb@freebsd.org, svn-src-all@freebsd.org, wkoszek@freebsd.org, src-committers@freebsd.org, rwatson@freebsd.org, brde@optusnet.com.au, freebsd-arch@freebsd.org, svn-src-head@freebsd.org Subject: Re: INCLUDE_CONFIG_FILE in GENERIC X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 18:06:14 -0000 In message: Marcel Moolenaar writes: : : On Jan 15, 2010, at 9:47 AM, Wojciech A. Koszek wrote: : : > On Fri, Jan 15, 2010 at 12:50:55PM +1100, Bruce Evans wrote: : >> On Thu, 14 Jan 2010, M. Warner Losh wrote: : >> : >>> In message: <86625798-F339-4863-8F97-63B5232A6CF7@freebsd.org> : >>> "Robert N. M. Watson" writes: : >>> : I agree. I see two kinds of users: : >>> : : > : > [..] : > : > Reasoning behind -C was that in 2007, Robert and Peter mentioned about a need : > of having comments in the config file. I divided users into two groups: : : Why don't we stop dividing people in groups and classes and : instead just add directives for what to include. Such as: : : embed options : embed devices : embed comments : embed includes : embed "$FreeBSD$" : : Combine this with syntactic sugaring and you can have something : like: : embed everything : noembed comments : : Is this really so hard? Yes. Didn't you read the message I posted about why this is hard? There would be a ton of lexer and parser work to make this happen, as well as a lot of work to internal data structures to keep the file as parsed, rather than as convenient to do config's job. It is a big pita. Right now there's two places where you can tap into the config file information. The first one is where we know the filename of the file we're configuring. The second is after all the lexing has happened and we know the options, but their order has been lost as well as any formatting and text. The latter was done to address concerns over the 'include' directive, but it has its own set of problems and isn't perfect either. I think the way forward isn't as you suggest. It would be a ton of work to fix the lexer to carry forward the comments. A comments directive is just plain silly. The embedding stuff is too fine-grained control. It is a bandaide on a bandaide over a kludge. What is needed really is a fresher approach to solving the problem correctly. I've been thinking hard about this. The better approach is actually very simple to implement and do, and is very extensible. Stay with me here for a moment. First, we change the section in the ELF file that contains the config file a little. This section will define a couple of symbols, with weak symbols backing them in kern/kern_mib.c (more on why that particular file later). This new section would be just a normal text file. The mib that exports the current config file would export this text file. The config -x command that looks for the config would still print out the same section of the file. So far, there's no change from what we have today, which is good. The reporting side can remain exactly as it is. However, we'd have config create a new file in the kernel directory. It would contain a list of all the files that were included (directly or indirectly) as part of the config parsing. This would also include not only files brought in by the 'config' directive, but also files brought in by the env or hints directives. This change is very small, and about a dozen lines of code to implement. I could produce a patch easily enough. The build process would change a little. Rather than config creating config.c, the build process would create it based on a dependency on this file and all the files in this file. The build scripts would then create a simple shar file of all the files listed in this file (included, env, hints, etc). This would be embedded in the kernel. This would solve the 'I forgot to save this included file' problem completely. It would solve the ordering problems we have without -C. It would solve the comments going away. Heck, we could have two options: one to include the entire src/sys tree (modulo binaries) and one to just include the config files. If there are space concerns, it can be made into a gzip -9'd tarball and no longer text for all I care :). But the src/sys option would be a little slow and really bloat the kernel. Now, the reason that kern/kern_mib.c was singled out is that's where we export this blob to userland. My idea is to keep the text format that we have now for compatibility, and I'd rather not have the mib do the decompression. But if we break with compat, then we can easily have the binary blob that's preserved there which can trivially be extracted either by config -x, or by the sysctl on the running kernel. Frankly, that sort of thing is the right way to fix the include problem. There's no space reason for including just a subset: it was purely an easy of implementation choice that drove the two ways. If we really make it include everything, then -C can go away, the weird pseudo thing we have can go away, and we know get everything. And it is easy to implement... Comments? Warner