lkml.org 
[lkml]   [2005]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] make miniconfig (take 2)
    Date
    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-11-26 13:29    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean