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: <20081124122055.GA18626@Krystal>
Date:	Mon, 24 Nov 2008 07:20:55 -0500
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	ltt-dev@...ts.casi.polymtl.ca, Zhaolei <zhaolei@...fujitsu.com>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	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

* Christoph Hellwig (hch@...radead.org) wrote:
> On Mon, Nov 24, 2008 at 06:28:42AM -0500, Mathieu Desnoyers wrote:
> > - trimmed-down lttv for the kernel tree
> >   Need to look at
> >   git://git.kernel.org/pub/scm/linux/kernel/git/sam/test.git#master
> >   tests/ directory, which permits building userspace tools with the
> >   Linux kernel. I recently got the idea of populating debugfs with
> >   userspace tools that would sits in kernel module data. How (in)sane
> >   does this idea look ? That would seems like a rather good solution to
> >   ship the userspace tool with the kernel.
> 
> Completely insane I'd say.  Debugfs is per defintion populated from
> kernelspace, and adding another mixed user/kernel populated fs like
> devfs is a rather bad idea.  I don't quite see any point in shipping
> lttv with the kernel tree either, it shouldn't really need knowledge of
> the kernel version.
> 

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 ?

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/