Messages in this thread | | | Subject | Re: [PATCH] tracing/profile: Fix profile_disable vs module_unload | From | Peter Zijlstra <> | Date | Tue, 25 Aug 2009 12:32:39 +0200 |
| |
On Tue, 2009-08-25 at 12:22 +0200, Ingo Molnar wrote: > * Peter Zijlstra <peterz@infradead.org> wrote: > > > On Tue, 2009-08-25 at 11:05 +0200, Ingo Molnar wrote: > > > * Peter Zijlstra <peterz@infradead.org> wrote: > > > > > > > Ah, my bad, I was thikning tracepoint_probe_register() was the > > > > thing that registered the tracepoint itself, not the callback. > > > > > > > > Ok, then what's the problem?, don't do modules that consume their > > > > own tracepoints, seems simple enough. > > > > > > is this a reasonable restriction? I dont see any reason why the > > > act of defining and providing a tracepoint should be exclusive > > > of the ability to make use of it. > > > > It doesn't make sense to me, you don't need your own tracepoints > > because you generate the events yourself, you already have them. > > For a reasonable large subsystem/driver i can very well imagine this > to happen: why should the subsystem add _another_ layer of callbacks > if it can reuse the generic tracepoint code and register itself to > those?
Then that subsystem would be non functioning when the kernel is build without tracepoints.
Nothing should rely on tracepoint being present, they are and should remain a debug feature, not a core hook thing.
Do you really wish to burden every tracepoint user with the extra logic needed to deal with modules?
| |