linux-kernel - Re: Dual-licensing LTTng, marker and tracepoints under GPLv2+/LGPLv2.1+

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID:  <loom.20090629T224818-688@post.gmane.org>
Date:	Mon, 29 Jun 2009 23:00:19 +0000 (UTC)
From:	Mark Wielaard <mjw@...hat.com>
To:	linux-kernel@...r.kernel.org
Subject:  Re: Dual-licensing LTTng, marker and tracepoints under	GPLv2+/LGPLv2.1+

Mathieu Desnoyers <compudj <at> krystal.dyndns.org> writes:
> * Frank Ch. Eigler (fche <at> redhat.com) wrote:
> > > [...]The goal is to permit this library, which includes the
> > > tracepoints, markers and LTTng features, to be used by userspace
> > > applications and libraries so they can add static instrumentation
> > > (as we currently do in the kernel). [...]
> > 
> > Just in case you're not aware, some API prior art for this is the
> > dtrace sdt.h widget (already supported by systemtap), and of course
> > it has no similarity to the various kernel tracing APIs.
> 
> Yep, we're aware of this. However, last time I checked, dtrace SDT used
> a breakpoint even for their userspace tracing, which has a way too large
> performance overhead for our needs.

You might want to check again. Although the systemtap sdt.h should be source
compatible with dtrace markers since it provides the same compile time
interfaces/macros (which is how systemtap support java hotspot probing for
example), it isn't tied to any implementation details. The default
implementation inserts a NOP that can be replaced by a breakpoint instruction.
But Stan Cox added variants that can use syscalls/utrace/kprobes which have
different performance overhead tradeoffs
(http://article.gmane.org/gmane.linux.systemtap/12667). This is an
implementation detail though since the source interfaces are the same. Just
recompiling your application and/or libraries against a newer version of the
sdt.h interfaces will automagically provide the different probe types.

Cheers,

Mark

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