Re: INCLUDE_CONFIG_FILE in GENERIC
- From: "Wojciech A. Koszek" <wkoszek@xxxxxxxxxxx>
- Date: Fri, 15 Jan 2010 18:47:11 +0100
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@xxxxxxxxxxx>
"Robert N. M. Watson" <rwatson@xxxxxxxxxxx> 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
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.
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:
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:
This is a list of my random ideas related with solving config(8) problems in
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
freebsd-arch@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"
- Re: INCLUDE_CONFIG_FILE in GENERIC
- From: Marcel Moolenaar
- Re: INCLUDE_CONFIG_FILE in GENERIC
- Prev by Date: Re: INCLUDE_CONFIG_FILE in GENERIC
- Next by Date: Re: INCLUDE_CONFIG_FILE in GENERIC
- Previous by thread: Re: INCLUDE_CONFIG_FILE in GENERIC
- Next by thread: Re: INCLUDE_CONFIG_FILE in GENERIC