15 Dec, 2010

3 commits


28 Oct, 2010

1 commit


04 Oct, 2010

1 commit


01 Oct, 2010

1 commit

  • commit 8baefd30b5b0101aa07aa75da44a9eee881eed28 of linux-next replaced
    a `switch()' statement with some `if()' statements, but left `break's
    in the `switch()' statement untouched. This cause read config loop to
    exit and so "make oldconfig" is not much usable (see below).

    > $ make oldconfig
    >
    > scripts/kconfig/conf --oldconfig Kconfig
    > #
    > # using defaults found in /boot/config-2.6.34-ccs-r1
    > #
    > *
    > * Restart config...
    > *
    > *
    > * General setup
    > *
    > Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [N/y/?] (NEW)

    (I've already have "CONFIG_EXPERIMENTAL=y" in the old config file. But
    that's not read here.)

    This patch should fix this problem.

    Signed-off-by: Naohiro Aota
    Signed-off-by: Michal Marek

    Naohiro Aota
     

20 Sep, 2010

3 commits


17 Aug, 2010

2 commits


15 Aug, 2010

1 commit

  • savedefconfig failed to save the correct minimal config
    when it encountered a choice marked optional.

    Consider following minimal configuration:
    $cat Kconfig
    choice
    prompt "choice"
    optional

    config A
    bool "a"

    config B
    bool "b"

    endchoice

    $cat .config | grep -v ^#
    CONFIG_A=y

    $conf --savedefconfig=defconfig Kconfig

    would before this fix result in an empty file, because
    kconfig would assume that CONFIG_A=y is a default value.
    But because the choice is optional the default is that
    both A and B are =n.

    Fix so we handle optional choices correct.

    Signed-off-by: Sam Ravnborg
    Signed-off-by: Michal Marek

    Sam Ravnborg
     

13 Aug, 2010

1 commit


12 Aug, 2010

2 commits

  • If a minimal config did not specify the value
    of all choice values, the resulting configuration
    could have wrong values.

    Consider following example:
    config M
    def_bool y
    option modules
    choice
    prompt "choice list"
    config A
    tristate "a"
    config B
    tristate "b"
    endchoice

    With a defconfig like this:
    CONFIG_M=y
    CONFIG_A=y

    The resulting configuration would have

    CONFIG_A=m

    which was unexpected.

    The problem was not not all choice values were set and thus
    kconfig calculated a wrong value.

    The fix is to set all choice values when we
    read a defconfig files.

    conf_set_all_new_symbols() is refactored such that
    random choice values are now handled by a dedicated function.
    And new choice values are set by set_all_choice_values().

    This was not the minimal fix, but the fix that resulted
    in the most readable code.

    Signed-off-by: Sam Ravnborg
    Reported-by: Arve Hjønnevåg
    Tested-by: Arve Hjønnevåg
    Signed-off-by: Michal Marek

    Sam Ravnborg
     
  • savedefconfig failed to save choice symbols equal to 'y'
    for tristate choices.
    This resulted in this value being lost.

    In particular is fixes an issue where

    make ARCH=avr32 atngw100_defconfig
    make ARCH=avr32 savedefconfig
    cp defconfig arch/avr32/configs/atngw100_defconfig
    make ARCH=avr32 atngw100_defconfig
    diff -u .config .config.old

    failed to produce an identical .config.

    Signed-off-by: Sam Ravnborg
    Signed-off-by: Michal Marek

    Sam Ravnborg
     

03 Aug, 2010

2 commits

  • savedefconfig will save a minimal config to a file
    named "defconfig".

    The config symbols are saved in the same order as
    they appear in the menu structure so it should
    be possible to map them to the relevant menus
    if desired.

    The implementation was tested against several minimal
    configs for arm which was created using brute-force.

    There was one regression related to default numbers
    which had their valid range further limited by another symbol.

    Sample:

    config FOO
    int "foo"
    default 4

    config BAR
    int "bar"
    range 0 FOO

    If FOO is set to 3 then BAR cannot take a value higher than 3.
    But the current implementation will set BAR equal to 4.

    This is seldomly used and the final configuration is OK,
    and the fix was non-trivial.
    So it was documented in the code and left as is.

    Signed-off-by: Sam Ravnborg
    Acked-by: Uwe Kleine-König
    Signed-off-by: Michal Marek

    Sam Ravnborg
     
  • Add a a few local functions to avoid some code duplication
    No functional changes.

    Signed-off-by: Sam Ravnborg
    Signed-off-by: Michal Marek

    Sam Ravnborg
     

29 Jul, 2010

1 commit

  • There seems to be a kconfig bug due to MODULES not always being
    evaluated if no .config is found. Take the following Kconfig as an
    example:

    config MODULES
    def_bool y

    config FOO
    def_tristate m

    With no .config, the following configuration is generated:

    CONFIG_MODULES=y
    CONFIG_FOO=y

    With an empty .config, the following:

    CONFIG_MODULES=y
    CONFIG_FOO=m

    Tristate choice statements can also exhibit the problem, due to having an
    implicit rev_dep (select) containing "m".

    The problem is that MODULES is never evaluted in conf_read_simple() unless
    there's a .config. The following patch fixes this.

    Signed-off-by: Ulf Magnusson
    Reviewed-by: WANG Cong
    Signed-off-by: Michal Marek

    Ulf Magnusson
     

26 Jul, 2010

1 commit


12 Dec, 2009

2 commits


20 Sep, 2009

1 commit


10 Jun, 2009

1 commit


16 Mar, 2009

1 commit

  • Ingo Molnar reported that 'make randconfig' was not covering
    choice blocks properly, resulting in certain config options
    being left out of randconfig testing altogether.

    With the following patch we:
    - properly randomize choice value for normal choice blocks
    - properly randomize for multi choice blocks
    - added several comments to explain what is going on

    The root cause of the bug was that SYMBOL_VALID was set on the
    symbol representing the choice block so clearing this did
    the trick initially.
    But testign revealed a few more issues that is now fixed.

    Reported-by: Ingo Molnar
    Cc: Ingo Molnar
    Cc: Roman Zippel
    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     

27 Oct, 2008

1 commit

  • If you use KCONFIG_ALLCONFIG (even with empty file) you get broken
    allmodconfig/allyesconfig; CONFIG_MODULES gets turned off, with obvious
    massive fallout.

    Breakage had been introduced when conf_set_all_new_symbols() got used
    for allmodconfig et.al.

    What happens is that sym_calc_value(modules_sym) done in
    conf_read_simple() sets SYMBOL_VALID on both modules_sym and MODULES.
    When we get to conf_set_all_new_symbols(), we set sym->def[S_DEF_USER]
    on everything, but it has no effect on sym->curr for the symbols that
    already have SYMBOL_VALID - these are stuck.

    Solution: use sym_clear_all_valid() in there. Note that it makes
    reevaluation of modules_sym redundant - sym_clear_all_valid() will do
    that itself.

    [ Fixes http://bugzilla.kernel.org/show_bug.cgi?id=11512, says Alexey ]

    Signed-off-by: Al Viro
    Cc: Sam Ravnborg
    Cc: Roman Zippel
    Cc: Alexey Dobriyan
    Signed-off-by: Linus Torvalds

    Al Viro
     

29 Sep, 2008

1 commit

  • Commit f072181e6403b0fe2e2aa800a005497b748fd284 ("kconfig: drop the
    ""trying to assign nonexistent symbol" warning") simply dropped the
    warnings, but it does a little more than that, it also marks the current
    .config as needed saving, so add this back.

    Signed-off-by: Roman Zippel
    Signed-off-by: Linus Torvalds

    zippel@linux-m68k.org
     

05 Aug, 2008

1 commit


26 Jul, 2008

1 commit


29 Jan, 2008

3 commits


18 Nov, 2007

1 commit

  • Simplify "make ARCH=x86" and fix kconfig so we again can set 64BIT in
    all.config.

    For a fix the diffstat is nice:
    6 files changed, 3 insertions(+), 36 deletions(-)

    The patch reverts these commits:
    - 0f855aa64b3f63d35a891510cf7db932a435c116 ("kconfig: add helper to set
    config symbol from environment variable")
    - 2a113281f5cd2febbab21a93c8943f8d3eece4d3 ("kconfig: use $K64BIT to
    set 64BIT with all*config targets")

    Roman Zippel pointed out that kconfig supported string compares so
    the additional complexity introduced by the above two patches were
    not needed.

    With this patch we have following behaviour:

    # make {allno,allyes,allmod,rand}config [ARCH=...]
    option \ host arch | 32bit | 64bit
    =====================================================
    ./. | 32bit | 64bit
    ARCH=x86 | 32bit | 32bit
    ARCH=i386 | 32bit | 32bit
    ARCH=x86_64 | 64bit | 64bit

    The general rule are that ARCH= and native architecture takes
    precedence over the configuration.

    So make ARCH=i386 [whatever] will always build a 32-bit kernel
    no matter what the configuration says. The configuration will
    be updated to 32-bit if it was configured to 64-bit and the
    other way around.

    This behaviour is consistent with previous behaviour so no
    suprises here.

    make ARCH=x86 will per default result in a 32-bit kernel but as
    the only ARCH= value x86 allow the user to select between 32-bit
    and 64-bit using menuconfig.

    Signed-off-by: Sam Ravnborg
    Cc: Roman Zippel
    Cc: Andreas Herrmann
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: "H. Peter Anvin"
    Signed-off-by: Linus Torvalds

    Sam Ravnborg
     

13 Nov, 2007

2 commits


17 Jul, 2007

1 commit

  • Normally generated values (Kconfig entries without a prompt) are cleared as
    they are regenerated anyway and so they appear as new should they become
    visible and defaults work as expected (once a value is set defaults aren't
    used anymore).

    The detection whether a value is generated or not is only based on its
    visibility status, which can quickly change for a lot of symbols by just
    removing a single line from .config or adding a dependency to Kconfig as you
    noticed.

    The patch now suppresses this logic when .config and Kconfig aren't in sync
    and .config needs to be updated, so that you can remove now a random value
    from .config and oldconfig won't reask for many other values.

    Signed-off-by: Roman Zippel
    Signed-off-by: Andrew Morton
    Signed-off-by: Sam Ravnborg

    Roman Zippel
     

14 Dec, 2006

3 commits

  • Added function sets "void (*conf_changed_callback)(void)". Call it, if
    .config's changed state changes. Use above in qconf.cc to set gui's
    save-widget's sensitvity.

    Signed-off-by: Karsten Wiese
    Cc: Sam Ravnborg
    Cc: Roman Zippel
    Acked-by: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Karsten Wiese
     
  • Those two functions are
    void sym_set_change_count(int count)
    and
    void sym_add_change_count(int count)

    All write accesses to sym_change_count are replaced by calls to above
    functions.

    Variable and changer-functions are moved to confdata.c. IMO thats ok, as
    sym_change_count is an attribute of the .config's change state.

    Signed-off-by: Karsten Wiese
    Cc: Sam Ravnborg
    Cc: Roman Zippel
    Acked-by: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Karsten Wiese
     
  • Run "make xconfig" on a freshly untarred kernel-tree. Look at the floppy disk
    icon of the qt application, that has just started: Its in a normal, active
    state.

    Mouse click on it: .config is being saved.

    This patch series changes things so taht
    after the mouse click on the floppy disk icon, the icon is greyed out.
    If you mouse click on it now, nothing happens.

    If you change some CONFIG_*, the floppy disk icon returns to "active state",
    that is, if you mouse click it now, .config is written.

    This patch:

    Returns sym_change_count to reflect the .config's change state.
    All read only accesses of
    sym_change_count
    are replaced by calls to
    conf_get_changed()
    .
    mconfig.c is manipulated to ask for saving only when
    conf_get_changed() returned true.

    Signed-off-by: Karsten Wiese
    Cc: Sam Ravnborg
    Cc: Roman Zippel
    Acked-by: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Karsten Wiese
     

01 Oct, 2006

1 commit

  • This fixes bugzilla entry: 7182
    http://bugzilla.kernel.org/show_bug.cgi?id=7182

    With this patch we no longer append the directory part twice
    before saving the config file.
    This patch has been sent to Roman Zippel for review with no feedback.
    It is so obviously simple that this should be OK to apply it anyway.

    Signed-off-by: Sam Ravnborg

    Sam Ravnborg
     

25 Sep, 2006

1 commit

  • Kconfig doesn't currently handle config files with DOS line endings.
    While these are, of course, an abomination, etc, etc, it can be handy
    to not have to convert them first. It's also a tiny patch and even adds
    support for lines ending in just \r or even \n\r.

    Signed-off-by: Matthew Wilcox
    Signed-off-by: Sam Ravnborg

    Matthew Wilcox