INCLUDE_CONFIG_FILE in GENERIC

[M. Warner Losh]

In message: <FE2858BE-2302-4980-BE73-32885AFBC7C2 at mac.com>
            Marcel Moolenaar <xcllnt at mac.com> 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 at freebsd.org>
: >>>           "Robert N. M. Watson" <rwatson at 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:
: 
: 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