INCLUDE_CONFIG_FILE in GENERIC

[M. Warner Losh]

In message: <D7A4BDAE-9CF6-45B3-8574-5E7DE89E2FCE at mac.com>
            Marcel Moolenaar <xcllnt at mac.com> writes:
: 
: On Jan 15, 2010, at 10:05 AM, M. Warner Losh wrote:
: > : Is this really so hard?
: > 
: > Yes. Didn't you read the message I posted about why this is hard?
: 
: No, I didn't.
: 
: > 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.
: 
: PITA != hard. If we're not willing to put in the effort to fix
: something, I don't think we should call it hard to do. We should
: call it like it is: non-trivial, involved or significant. Heck,
: we can even call it a major undertaking. But hard? No, I don't
: think it's hard at all.

Agreed.  But having retrofitted grammars in the past, coupled with the
fact that config doesn't create a proper parse tree means we'd be
rewriting huge portions of config, almost a complete rewrite from
scratch, I'd say, would be necessary.  And then you've sunk a huge
amount of time into solving a tiny problem.  Rewriting config should
produce more benefits than just this one problem.  That's why I called
it hard.

: > I think the way forward isn't as you suggest.
: 
: Fine. Just stop trying to classify people as a basis for what
: behaviour we should implement. It never works...

Actually, engineering is all about identifying classes of users, and
showing that solutions map well onto those classes of users.  In
showing which classes of users the solutions works well for, we can
also find holes in the current setup.

: > 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?
: 
: How does this address the "I don't want everything, I just want
: my CVS keyword" example? How does it handle the delicate balance
: between space vs. functionality that exists on embedded and/or
: low-end platforms. An all inclusive implementation seems not to
: take that into account that well. Sure, you can compress but
: then you add a runtime overhead to uncompress.

I don't understand the "I just want my CVS keywords expanded"
example.  I think that's an orthogonal problem entirely (and maybe a
small bug-fix to config to include an ident keyword if people really
want the config file saved).  The CVS keywords for the rest of the
kernel are controlled by sys/cdefs, which creates .ident lines which
the toolchain is responsible for keeping or ditching.

Embedded platforms wouldn't embed the whole config file at all, so I
don't see what we do for platforms that aren't resource sensitive
would matter here.  But all the includes is only 14k on amd64 and i386
(our biggest config file platforms).  These particular config files
compress down to about 6k.  Embedded config files tend to be even
smaller, and would likely compress down to about 1.5k-2k (AR71XX is
1.3k without the extra included files).  Since the kernel is itself
compressed, we wouldn't have to worry too much about it.  So even in
embedded, the resources consumed are small.

: In any case: I personally don't use the option so I really should
: not get involved. If I were to implement something from scratch
: though, I would treat it as a C file: the config file is the source
: and you "compile" it into a binary form suitable for inclusion into
: the kernel and you have compile-time options that control the binary
: output. No comments will be included in that case and there will be
: no option for it. But that's just me...

That's basically what's implemented to day: we're but a whisper away
from a pure binary for (no -C)...

Warner