Messages in this thread | | | Date | Wed, 1 Oct 2003 21:47:43 +0200 (CEST) | From | Guennadi Liakhovetski <> | Subject | Re: RFC: [2.6 patch] disallow modular IPv6 |
| |
On Tue, 30 Sep 2003, David Woodhouse wrote:
> On Mon, 2003-09-29 at 22:17 -0700, David S. Miller wrote: > > On Mon, 29 Sep 2003 10:02:55 +0100 > > David Woodhouse <dwmw2@infradead.org> wrote: > > > > > 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
- 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/
| |