linux-kernel - Re: LTTng kernel integration roadmap, update

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

Message-ID: <alpine.DEB.1.10.0811241156030.20122@gandalf.stny.rr.com>
Date:	Mon, 24 Nov 2008 11:58:40 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
cc:	Christoph Hellwig <hch@...radead.org>,
	ltt-dev@...ts.casi.polymtl.ca, Zhaolei <zhaolei@...fujitsu.com>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...l.org>, Sam Ravnborg <sam@...nborg.org>
Subject: Re: LTTng kernel integration roadmap, update


On Mon, 24 Nov 2008, Mathieu Desnoyers wrote:
> 
> The key idea behind this is to answer to Thomas Gleixner concerns, who
> supports that a tracer should output data in text-format only so it can
> be used with tools kernel developers have on their system, like "cat".
> 
> However, getting data out of the kernel efficiently simply cannot be
> done with such approach. Therefore, LTTng needs its own userspace tools
> to splice the data out of the kernel efficiently. Another tool is used
> to pretty-print the binary data into text.
> 
> Then the problem becomes : we have to make the userspace tool easy
> enough to deploy so even Linus can find and use it. ;)
> 
> But indeed, the trace buffers are versioned, so if the format changes
> between kernel versions, the userspace tools will detect it and the user
> will know it must update its tools. So it's not really a problem there.
> 
> The question that prevails is therefore : should we ship userspace
> binary with the kernel tree at all ? And if yes, how should the resuting
> executables be packaged and deployed ? Should it be installed in the
> system along with kernel modules or should it be populated into a
> filesystem populated by kernelspace ?
> 
> Or is it better to do as we have always done and keep the userspace
> tools separated from the kernel tree ?

I say keep the user space tools separate as much as possible.

What about having a meta-data file for all binary files. This meta-data 
could explain the format that is read. Big endian, little endian, the 
fields and offsets, the event ids etc.  This way we will not need a 
"version" file, which means absolutely nothing if you do not know what 
comes with that version. Any tool could look at the meta-data file and 
figure out what is in the buffers.

-- Steve

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