On Tue, 30 Sep 2003, David Woodhouse wrote:

On Mon, 2003-09-29 at 22:17 -0700, David S. Miller wrote:

quoted

On Mon, 29 Sep 2003 10:02:55 +0100
David Woodhouse [off-list ref] wrote:

quoted

The underlying point being that your static kernel should not change if
you change an option from 'n' to 'm'. It should only affect the kernel
image if you change options to/from 'y'.

I totally disagree, what ipv6 is doing is perfectly fine.

Your right.

Well, maybe you are right, but I certainly liked the feature, that I could
just add a module to a currently running kernel's configuration, compile
and insmod it. But, if this is how it is (going to be) now - that one
shouldn't rely on this, do you agree, that such attempts should be stopped
by the build system? If so, I think, a script, trying to find possible
problems could be of help? It wouldn't be trivial, but maybe there's
already framework available, that can be taught to do this? Ideally, you
would want to check:
for each tristate CONFIG_ find from the respective Makefile(s) which
source (*.[Sc])-files are involved with obj-$(CONFIG_x). Find depending
source-files from "depends on x" in respective Kconfig recursively. If
CONFIG_x appears in any other source-files - it is already a (likely)
problem. Now headers. Well, if we want to check infinitely deep inclusions
- it would require a fat cluster / SMP, I guess:-) So, is there a piece of
software among all automatic checkers, that could be relatively easily
taught to do this and would it make sense to run such a check on each -pre
and -rc version?

Actually, is anybody checking for recursive includes?

Guennadi
---
Guennadi Liakhovetski