Hi Keith.
>> Can I suggest you re-read your comment and the points you quoted
>> and said are correct. As a DIRECT logical consequence of "(1)
>> and (3) are correct" (as you phrased it), we get the conclusion
>> that any config lines that depend on "if some arch is set" (as
>> you phrased it) are in the architecture-specific config files.
>> This leads DIRECTLY to the conclusion that ANY lines dependant
>> on a particular architecture that are not in the
>> architecture-specific config files are a bug in the kernel
>> config scripts.
> No. We want network drivers to be in the network menu, SCSI
> drivers in the SCSI menu etc. Some of those drivers are
> restricted to some architectures but putting them in the arch
> config splits the logical flow of selection and duplicates text.
> Look at the repeated SCSI code in some of the arch configs.
That's a direct consequence of the policy quoted in paragraph (3) and
NOT an error in the logic. It's why I'm against the current policy.
>> 2. dep_arch_tristate CONFIG_var CONFIG_arch [CONFIG_other_var...]
> dep_arch_tristate ' AM79C961A support' CONFIG_ARM_AM79C961A \
> $CONFIG_ARCH_ACORN $CONFIG_NET_ETHERNET
> fails your code. $CONFIG_ARCH_ACORN is undefined,
> $CONFIG_NET_ETHERNET is 'y'. dep_arch_tristate is invoked with
> 3 (not 4 parameters), text, CONFIG_ARM_AM79C961A and 'y'. The
> intervening undefined variable disappears in shell scripts.
You're not thinking clearly. Try the following simple fix to that:
Q> dep_arch_tristate ' AM79C961A support' CONFIG_ARM_AM79C961A \
Q> "$CONFIG_ARCH_ACORN" $CONFIG_NET_ETHERNET
That adds only two extra characters, neither conspicuous, and PASSES
my code.
Best wishes from Riley.
-
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/
This archive was generated by hypermail 2b29 : Sat Jul 07 2001 - 21:00:09 EST