[lkml]   [2001]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.4.6p6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs
On Sat, 30 Jun 2001 21:36:26 +0100 (BST), 
Riley Williams <rhw@MemAlpha.CX> 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/*/
> 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


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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:55    [W:2.090 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site