Kconfig bug (was: Re: fault-injection framework on ia64)

Kconfig bug (was: Re: fault-injection framework on ia64)

[Blaisorblade]

On Friday 16 February 2007 18:30, Akinobu Mita wrote:
> > But if STACKTRACE depends on STACKTRACE_SUPPORT, which isn't defined on
> > ia64, kconfig should disable FAULT_INJECTION altogether with my patch (as
> > it did before it). I don't think that FAULT_INJECTION could be enabled
> > before my patch, right?
> >
> > _BUT_ probably STACKTRACE_SUPPORT should be defined, with default n and
> > no prompt, on ia64, or Kconfig gets confused (it should output a warning,
> > like 'undefined symbol STACKTRACE_SUPPORT'). We on UML used to get
> > warning when INPUT was used but not defined. Hmmm....
>
> Really? I intentionaly removed the STACKTRACE_SUPPORT in x86_64 Kconfig,
> then I did make menuconfig. But I didn't get such warning.
Well, I got that warning, and I don't get it on STACKTRACE_SUPPORT. Strange. 
But it was time ago...

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?

This Kconfig bug explains how your bug could surface.

This also means that my patch cannot to go -stable because it would cause 
problems on IA64 and any arch without STACKTRACE_SUPPORT.
See if yours can, Akinobu.
-- 
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 

Re: Kconfig bug (was: Re: fault-injection framework on ia64)

[Roman Zippel]

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?

bye, Roman

Re: Kconfig bug (was: Re: fault-injection framework on ia64)

[Blaisorblade]

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.

I hope things are now clearer, even without the description of the testcase 
where this happened.
-- 
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 

Re: Kconfig bug (was: Re: fault-injection framework on ia64)

[Roman Zippel]

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.

bye, Roman

Re: Kconfig bug (was: Re: fault-injection framework on ia64)

[Blaisorblade]

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