Re: [PATCH] tracing/profile: Fix profile_disable vs module_unload

From: Ingo Molnar
Date: Tue Aug 25 2009 - 06:39:26 EST



* Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:

> On Tue, 2009-08-25 at 12:22 +0200, Ingo Molnar wrote:
> > * Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> >
> > > On Tue, 2009-08-25 at 11:05 +0200, Ingo Molnar wrote:
> > > > * Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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.

... except if it selects all required core kernel functionality it
relies on? Tracepoints and typed callbacks really go hand in hand
and it would be nice to see some more synergy in that space.
(instead of crappy, prioritized notifier chains for example.)

> 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?

Not necessarily - i'm just outlining why i think that the 'dont
allow subsystems to utilize tracepoint callbacks' is a restriction
we should not live with voluntarily.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/