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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
