On Friday 16 February 2007 23:26, Roman Zippel wrote: > Hi, > > On Fri, 16 Feb 2007, Blaisorblade wrote: > > On Friday 16 February 2007 20:12, Roman Zippel wrote: > > > Hi, > > > > > > On Fri, 16 Feb 2007, Blaisorblade wrote: > > > > However, more important, if I remove STACKTRACE_SUPPORT, or if I make > > > > it 'default n', FAULT_INJECTION can still be enabled, even if it > > > > selects STACKTRACE which has a failed dependency (tested on UML). > > > > Which is a Kconfig bug - if A selects B and B depends on C, no > > > > dependency of A on C is deduced. Right Roman? > > > > > > Correct, but could someone please give me some more context, what the > > > bug is supposed to be here? > > > > Hmm. > > You agree that "if A selects B and B depends on C, no dependency of A on > > C is deduced", right? > > > > The implication is that the user can enable A, which selects B, while C > > is still disabled. The B -> C dependency is violated, and the build will > > fail or bad things will happen. > > Indeed, that's why in this case everything that selects STACKTRACE depends > on STACKTRACE_SUPPORT. Ah. Ok... so this 'bug' can be workarounded. But couldn't it be fixed or at least documented as pitfall? A depends on B is similar, from this point of view, to "A selects B", and they could be treated together for recursive dependency analisys. -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|