Re: 2.4.6p6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs

[Keith Owens]

On Sat, 30 Jun 2001 21:36:26 +0100 (BST), 
Riley Williams <[e-mail]> wrote:
> 1. Adam's point is that there are dep_* statements in the config
>    setup that have been used to say that a particular option is
>    dependant upon a particular architecture, but this doesn't work.
>
> 3. MY understanding of the situation is that ALL architecture
>    specific config lines are EXPECTED to be in the arch/*/config.in
>    files, where they will only even be seen when the relevant
>    architecture is being compiled for.
>
>As a result of this, I would summarise this discussion as saying that
>there is a bug in the kernel config scripts in that some options that
>should be located in the architecture-specific config files are in the
>all-architecture config files instead.

(1) and (3) are correct but your conclusion is not.  The problem is

  dep_tristate CONFIG_some_driver $CONFIG_some_arch

where the intention is to allow the driver only if some_arch is set.
When you compile for some_other_arch, CONFIG_some_arch is undefined.
dep_tristate treats undefined variables as "don't care" and we cannot
fix that without changing bash or a major rewrite of the shell scripts.
There are two solutions, either change all such lines to

  if [ "$CONFIG_some_arch" = "y" ];then
    tristate CONFIG_some_driver
  fi

or

  define_bool CONFIG_some_arch n

for all architectures at the start, followed by turning on the one that
is required.

Lots of if statements are messy and they will not prevent somebody
adding new options with exactly the same problem.  Explicitly setting
all but one arch variable to 'n' results in cleaner config scripts and
new arch dependent driver settings will automatically work.