Date: Fri, 15 Jan 2010 18:47:11 +0100 From: "Wojciech A. Koszek" <wkoszek@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: dougb@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, rwatson@freebsd.org, freebsd-arch@freebsd.org, svn-src-head@freebsd.org Subject: Re: INCLUDE_CONFIG_FILE in GENERIC Message-ID: <20100115174711.GF1990@FreeBSD.org> In-Reply-To: <20100115114822.O63406@delplex.bde.org> References: <20100114.105622.457034909117828677.imp@bsdimp.com> <4B4F7810.2080003@FreeBSD.org> <86625798-F339-4863-8F97-63B5232A6CF7@freebsd.org> <20100114.135930.80200584442733547.imp@bsdimp.com> <20100115114822.O63406@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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" <rwatson@freebsd.org> 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: - those who don't care because they can't reconfigure the FreeBSD kernel anyway no matter what - with or without comments, they're baked anyway, because "make xconfig" doesn't work. - those who don't care in which format config file is, since they just glance at the output from config -x, use Copy's and Paste's method and get everything fixed; preprocessing of configuration files was done for them and for system administrators woken up at 3am with a task of recreating exact machine configuration. I don't want to argue on my view, but I glanced at Warner's patch and if people want it, I believe it can make our world a bit better. > "Stripping" comments has nothing to do with saving space. It is because > it is technically difficult, and not implemented, to not strip them, > except in the old limited code that just preserves the unprocessed > top-level-only config file. This is exactly why comments aren't there. Below in this thread, Peter Jeremy gives us good suggestion on bringing additional option like "comment", which would include string literal. I think this is a good proposal. >> : As such, I see a reasonable "default" -- i.e., i386/amd64 GENERIC -- >> : be to fully preserve the configuration and its comments. For the > > Your code to implement this is welcome :-). Even GENERIC is not quite > complete, since it is missing the implicit include of DEFAULTS. OTOH, > completing the config by merging with DEFAULTS, as I think the processed > version must do, may give an unusable config by repeating things in > DEFAULTS. The merge should probably have no processing at all, with > include files concatenated and not replacing include directives, and > DEFAULTS not included. My opinion is that DEFAULTS should be included in every GENERIC explicitly by include directive, and that the code dealing with DEFAULTS which is right now present in config(8) should be removed. >> 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 assumption is false, so this model became just broken when the > include directive was implemented. History: > INCLUDE_CONFIG_FILE option: 1996 > include directive: 2001 > processed output and -C: 2007 > The -C option just preserves the breakage at its 2001-2007 level. I just tried to make is "suck less", so -C right now takes all "include <FILE>" directives and brings <FILE> in configuration file. >> 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). > > ISTR a long discussion about the -C option when it was implemented. Why > didn't you complain back then? :-). I looked at my old mail about this. > I wasn't involved with the initial discussion, but imp was :-). My mail > was after the initial commit. I reported the following problems: Warner was within a very small group of people that actually did care about config(8) when I touched it, and helped me to fix world/config(8) breakage when people on DevSummit (BSDCan?) couldn't get their kernel to configure properly. > - DEFAULTS wasn't processed I don't seem to remember this one... With -C it's not included, but I propose a solution above. Is this an issue you're referring here? > - several ordering problems. Ones that reordered directives of the form: > options FOO=bar > nooptions FOO > options FOO=baz > made the generated file unusable. This was found and fixed thanks to your devil's configuration tarball. Anyway... Each time I see our kernel modules being built I cry and think of this page: http://wiki.freebsd.org/NewConfig This is a list of my random ideas related with solving config(8) problems in long run. Without promising anything I can say that narrowing requirements down would help me to figure out, how big the problem is. Maybe I could help somehow with the configuration file mess in the future.. Mail me your suggestions privately, and I'll bring them to the Wiki. -- Wojciech A. Koszek wkoszek@FreeBSD.org http://FreeBSD.czest.pl/~wkoszek/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100115174711.GF1990>