INCLUDE_CONFIG_FILE in GENERIC

[M. Warner Losh]

In message: <86625798-F339-4863-8F97-63B5232A6CF7 at freebsd.org>
            "Robert N. M. Watson" <rwatson at freebsd.org> 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