From: Randy.Dunlap <rdd...@os...> - 2002-11-20 04:45:24
|
On Wed, 20 Nov 2002, Bharata B Rao wrote: | On Thu, Nov 14, 2002 at 03:52:31PM -0800, Randy.Dunlap wrote: | > | > Well, I turn off CRASH_DUMP, but there's still some crashdump code | > in the kernel, and that's not a good thing. When trying to isolate | > problems, config options need to be able to eliminate code | > (and preferably data) completely, and I don't quite see LKCD | > doing that. Am I wrong about that? I'd like to be. | > Is someone already working on making this happen? | > | > (I can do this in my source tree for my testing purposes, but I | > really think it needs to be done in the lkcd sources.) | > | | While porting lkcd to 2.5, one of the feedbacks we got from lkml | is to make as much code independent of CONFIG_CRASH_DUMP as possible. | And making sure that normal behaviour is not altered when | CONFIG_CRASH_DUMP is turned off. The result is that most of the code | was moved out of #ifdef CONFIG_CRASH_DUMP(see utils.patch for eg.) | | Do you see any lkcd code outside CONFIG_CRASH_DUMP which changes | the behaviour (significantly) when it is not turned on ? No, I can't say that I do, although my personal goal is not "significantly," it's "at all." I guess I need to go back and re-read that feedback and re-evaluate it. Can you point me to those remarks? IMO there is some value in being able to generate zero code if a CONFIG option is turned off. For one thing, it can remove any doubts or suspicions or behavioral changes. If there is extra code there when an option is disabled, that leaves room for suspicion. Could the feedback have meant that the source code shouldn't be littered with #ifdef CONFIG_CRASH_DUMP in lots of places? That's a slightly different issue, I believe. -- ~Randy |