Re: [PATCH] make miniconfig (take 2)

[Rob Landley]

On Friday 25 November 2005 20:34, Kyle Moffett wrote:
> I got interested so I started writing a Perl-based replacement that
> actually reads the source config into program memory and writes
> copies out of that RAM each time.

I did several variants before settling on the one I submitted as "least sucky 
for right now".  (Starting from zero and adding lines did not work at _all_, 
and trying to produce consecutively smaller diffs isn't a winner either.  
Anything fancy based on diff runs into the fact that dependencies can enable 
stuff _earlier_ in the file, and it's almost impossible to parse.  Besides, 
diff is noticeably faster when there are few changes, so this was the best 
performer of the lot too...)

And I try to avoid perl dependencies in the linux build process.  When you do 
cross-compiles that make a minimal toolchain (ala the Linux From Scratch 
"/tools" directory) and then chroot into it to create the new system, having 
to add perl to the mess is a disproprotionate hassle.

> I ran into a problem (although I can't reproduce it anymore) where the
> resultant configs had identical options but slightly altered whitespace or
> ordering, which naturally broke the diff method that miniconfig.sh used.

Not a clue, sorry.  The date stamp changes, but that's expected white noise...

> >> I'm not sure what I did wrong last time, it worked this time. My
> >> miniconfig is 6K instead of 46K, good. Still its quite long. Thanks!
> >
> > You mentioned you set a lot of options. :)
> >
> > I agree scripts/miniconfig.sh is clumsy.  I'm thinking about
> > improvements (both to how it works and to the user interface), but
> > I need to catch up on some other stuff first...
>
> I have a bit of time to tinker.  I'll send you my perl version once I
> get it working and test it out a bit.  It shouldn't be too hard to
> add the ability to use .config and rewrite that when exiting.

I came back up to speed on Perl earlier this year (having last used perl 4 
before that), and reminded myself why I really can't stand it.  (scalar vs 
list context, local is an abuse of the exception handler, javadoc didn't have 
to modify the interpreter to ignore /** */ markup, pervasive use of call by 
reference means the exact same operator can act like a comparison or an 
assignment based on context ($x=~blah vs $x=~s/a/b/), references were nailed 
to the side of the language horribly, no language should force every program 
to start with a "suck less than the default" directive like use strict...  I 
could go on for a while...)  If I was going to bang on something more 
advanced than bash I could do a python version easily, but I don't want to 
assume that the target environment will have Python.

The dominant time factor is running allnoconfig.  (Last I checked anyway, 
there's been some development under the bridge since then, might be worth a 
re-profile.)  One speed improvement is that it should be possible to zap some 
of the comment lines without doing an actual allnoconfig.  (Certainly when 
there's a range of contiguous comment lines it could try zapping all of them 
and only iterating through one at a time if that makes a behavior difference, 
which it very seldom should.  That's a low-hanging fruit.)

Also, zappable lines tend to clump, so if it gets 2 zappable lines in a row it 
could speculatively try zapping 2 at a time to see if it makes faster 
progress.  (The down side is the extra allnoconfig runs for backing up and 
iterating through on failures to see _which_ ones made a difference.  That's 
not low-hanging fruit, may not be edible at all...)

> One other minor nit:  If you pass a config file from a previous
> version to miniconfig.sh, it will return the full config file because
> nothing makes it match the original.
>
> Theoretically it should 
> probably allnoconfig with the full config first and use that for the
> rest, before removing lines.

Yup.  That's an upgrade I already have planned.  Right now the mini.config 
files aren't version specific but the shrinker is, but that's easily fixable 
for 2.0.

I kept the shrinker script minimalistic because I was hoping that the kconfig 
guys might like the idea enough to make kconfig's existing infrastructure 
spit out a mini.config, rendering the script obsolete.  But now it's clear 
their reaction is intense distain, I might as well improve my hack since it 
looks like I'll be stuck with it for a while...

I'm pondering making a self-contained "./configure" wrapper script that 
obsoletes my patch (since they refuse to apply it anyway).  The question is 
should it rely on the new "allnoconfig" behavior, or should it just do 
everything with sed so it works with older Linux versions (and busybox and 
uclibc and so on)?  Haven't decided yet.

(Under ./configure, miniconfig.sh would probably become "./configure --export" 
or some such...)

> Cheers,
> Kyle Moffett

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/