linux-kernel - Re: [PATCH 2/4] tracing: add event trace infrastructure

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]

Date:	Wed, 25 Feb 2009 11:27:25 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Theodore Tso <tytso@....edu>,
	Arjan van de Ven <arjan@...radead.org>,
	Pekka Paalanen <pq@....fi>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Jason Baron <jbaron@...hat.com>,
	Martin Bligh <mbligh@...gle.com>,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Jens Axboe <jens.axboe@...cle.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Steven Rostedt <srostedt@...hat.com>
Subject: Re: [PATCH 2/4] tracing: add event trace infrastructure

* Andrew Morton <akpm@...ux-foundation.org> wrote:

> On Wed, 25 Feb 2009 10:56:23 +0100 Ingo Molnar <mingo@...e.hu> wrote:
> 
> > Since the concept of a kernel tracing facility being 
> > self-sufficient and being easy to use is an integral and key 
> > concept to ftrace, dont you see why people take your 
> > suggestions as a dismissal of the ftrace concept?
> 
> Nothing I've suggested in any way makes ftrace hard to use.

Note that everything you suggest is _already possible_, if you 
switch on the 'make simple output' option. It's just that the 
human-readable format is the default one.

So i think your suggestion does make ftrace harder to use, in a 
number of ways:

 - There's one more extra tool to be installed on the target
   machine. That target machine might not even have any build
   environment - but tracing on it can still be very useful to 
   pin down bugs and regressions.

   Self-sufficient kernel instrumentation is a key concept to
   usability.

 - That tool will break the current intuitive shell-commands and 
   scripting flow that is based on human readable text output.

   In ftrace we try to strike a good balance between easy
   scriptability and pretty-printing. The two go hand in hand 
   usually so it's not a big task. If you look at the current 
   /debug/tracing/trace output you'll find a lot of small 
   details that we've put in there to make it easy to script - 
   while still being nice to read. [suggestions to improve it 
   are welcome.]

   Your suggestion pushes that completely to the 'minimal 
   output' direction, with no tangible benefit to scripting, and 
   with a lot of damage to readability and usability. A separate
   pretty-printing tool would just add an extra unnecessary step
   and would make the workflow more clumsy. This too is a clear
   step backwards.

 - Plus the extra effort of defining APIs and ABIs to it and the
   extra effort to make it work on all kernel versions. It all
   takes away resources from making tracing more useful in
   practice so it indirectly hurts instrumentation usability. 

   Tracing development manpower is a zero-sum game. If you force 
   people to maintain silly APIs you take away time from other, 
   more important areas. It might even be a negative-sum game: 
   developing something that looks ugly and is hard to use 
   attracts less developers. Tracing under Linux was in such a
   zombie state for a decade and ftrace clearly changed that 
   picture. I dont subscribe to the view that tracing has to be
   stupid and boring.

I.e. i dont see many upsides of your suggestion, and i see a lot 
of downsides.

IMO pretty-printing in the kernel should not be made a religious 
argument but a technical argument. Pretty-printing is a tool, 
and as a tool it sometimes can be used for silly purposes, and 
sometimes it can be used for helpful purposes. You seem to argue 
that doing it in the kernel is always silly - and i strongly 
disagree with that and consider it an extreme-end position - for 
the reasons outlined above.

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