Thread (15 messages) flat view 15 messages, 5 authors, 2009-03-24

Re: [PATCH] tracing: Fix TRACING_SUPPORT dependency

From: Ingo Molnar <hidden>
Date: 2009-03-21 16:18:57
Also in: lkml

* Anton Vorontsov [off-list ref] wrote:
On Fri, Mar 20, 2009 at 08:57:43PM +0100, Ingo Molnar wrote:
quoted
* Anton Vorontsov [off-list ref] wrote:
quoted
On Fri, Mar 20, 2009 at 08:04:28PM +0100, Ingo Molnar wrote:
quoted
* Anton Vorontsov [off-list ref] wrote:
quoted
commit 40ada30f9621fbd831ac2437b9a2a399aad34b00 ("tracing: clean 
up menu"), despite the "clean up" in its purpose, introduced 
behavioural change for Kconfig symbols: we no longer able to 
select tracing support on PPC32 (because IRQFLAGS_SUPPORT isn't 
yet implemented).
Could you please solve this by implementing proper 
irqflag-tracing support? It's been available upstream for almost 
three years. It's needed for lockdep support as well, etc.
Breaking things via clean up patches is an interesting method of 
encouraging something to implement. ;-)

Surely I'll look into implementing irqflags tracing, but 
considering that no one ever needed this for almost three years, 
[...]
Weird, there's no lockdep support?
*ashamed*: apparently no such support currently exist for PPC32. ;-)
Hm, do all the tracers even compile on ppc32 with your patch?

We had periodic build failures on weird, unmaintained architectures 
that had no irqflags-tracing support and hence didnt know the 
raw_irqs_save/restore primitives ...

I'm not trying to make things more difficult for you (and we can 
apply your patch if it builds fine and does not cause problems 
elsewhere), but there were some real downsides to not having proper 
irq APIs ...

	Ingo
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help