lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 26 Oct 2009 12:11:23 -0400
From:	Mathieu Desnoyers <>
To:	Steven Rostedt <>
Cc:	Pierre-Marc Fournier <>,
	Ingo Molnar <>, GeunSik Lim <>,
	Zhaolei <>,
	Wu Fengguang <>,
	Jesper Juhl <>, Adrian Bunk <>,
	Harvey Harrison <>,
	"Robert P. J. Day" <>,
	Jaswinder Singh Rajput <>,
	Frederic Weisbecker <>,
	Lai Jiangshan <>,
	KOSAKI Motohiro <>,,
	Dominique Toupin <>,
	Michel Dagenais <>
Subject: Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL
	v2,headers to Dual BSD/GPL

* Steven Rostedt ( 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.



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
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists