Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPLv2,headers to Dual BSD/GPL

From: Mathieu Desnoyers
Date: Mon Oct 26 2009 - 12:16:32 EST


* Steven Rostedt (rostedt@xxxxxxxxxxx) wrote:
> On Mon, 2009-10-26 at 09:17 -0400, Pierre-Marc Fournier wrote:
> > Ingo Molnar wrote:
> > >
> > > But i also disagree with it on a technical level: code duplication is
> > > _bad_. Why does the code have to be duplicated in user-space like that?
> > > I'd like Linux tracing code to be in the kernel repo. Why isnt this done
> > > properly, as part of the kernel project - to make sure it all stays in
> > > sync?
> > >
> >
> > If you mean that this code should solely be used inside the kernel, then
> > what you propose technically does not work. There is a very high cost to
> > accessing kernel code from userspace. This cost is simply unacceptable
> > for the kind of userspace tracing that is needed today.
>
> I think that Ingo is thinking that the tracing is for the kernel, and is
> asking why the duplication needs to be done for tools tracing the
> kernel.
>
> But what I think is trying to be done here is to use the same types of
> MACROS that we have in the kernel to do tracing in userspace. That a
> userspace program can add their own "TRACE_EVENT" and that the headers
> there will create a tracepoint for them the same way we currently do in
> the kernel.
>
> Am I correct in my analysis?
>
> -- Steve
>

Hi Steve,

Yes, you are correct about the intent of making the static
instrumentation macros available to userspace. This is indeed our goal.

What Ingo is trying to propose (I guess) is to perform tracing through
the kernel (e.g. probably through a vDSO or syscall).

However, the licensing question here is for tracepoints, markers,
trace_event, which is a _static instrumentation_ mechanism. In this
case, the kernel cannot really help, because we have to build the
instrumentation into the application anyway, so we run into these
license problems, and it cannot be magically solved by the kernel. Or
maybe Ingo has a different perspective on static instrumentation that
would involve the kernel ? If it's the case, then I'd like to hear it.

Thanks,

Mathieu


--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
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/