linux-kernel - LTTng 0.66 (dynamic channel allocation, markers modifications)

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>] [day] [month] [year] [list]

Message-ID: <20081213214646.GA23687@Krystal>
Date:	Sat, 13 Dec 2008 16:46:46 -0500
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	ltt-dev@...ts.casi.polymtl.ca
Cc:	Linus Torvalds <torvalds@...l.org>, Andrew Morton <akpm@...l.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: LTTng 0.66 (dynamic channel allocation, markers modifications)

Hi,

I just finished a big development iteration on LTTng/markers. It updates
the following tools :

LTTng 0.66, ltt-control 0.60, LTTV 0.12.0

And it changes the trace version number to 2.3.

Those were the last major changes I had to do to LTTng before releasing
it to LKML. It includes :

- Dynamic allocation of channels.
- Channels are declared in a supplementary marker parameter.
- Event IDs are now managed by the marker infrastructure.
- Event IDs are now dynamically allocated per-channel.

With these changes, changing any tracer so it uses the LTTng buffering
mechanism becomes as trivial as declaring a marker (DECLARE_MARKER())
and using the reference to the marker structure in a probe callback to
send the information into LTTng trace buffers. Many traces can be active
at once, each with their own set of active channels. Therefore, a given
tracer might only want to enable its own channel and the metadata
channel so it only gets its own information.

So in the current marker implementation, the marker declaration is
responsible for associating a data source with a :

- Channel
- Event ID within this channel
- Field types (format string)

Currently, the last element missing is the ltt-ascii.ko kernel module
which pretty-prints the information from within the kernel. The trace
clock time-base might not be as shiny as people would want it to
(especially wrt non-synchronized TSCs), but it works. I guess I'll have
to give it another good look before I resubmit it though.

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/