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 10:56:23 +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:

> Plus...  it's all English-only.

Note that with bin+raw output you can already internationalize 
tracepoints, if you want to.

I havent seen much interest in that, and the default tracing 
output is in English indeed, and the reason is rather 
fundamental: currently we've got 60,000+ kernel function 
symbols, 99% of which are in English.

Do you argue for them to be converted to some i8n format so that 
the trace output becomes readable in other languages as well? 

I.e. do you suggest that this:

>  3)               |  handle_mm_fault() {
>  3)               |    count_vm_event() {
>  3)   0.243 us    |      test_ti_thread_flag();
>  3)   0.754 us    |    }
>  3)   0.249 us    |    pud_alloc();
>  3)   0.251 us    |    pmd_alloc();
>  3)               |    __do_fault() {
>  3)               |      filemap_fault() {
>  3)               |        find_lock_page() {
>  3)               |          find_get_page() {
>  3)   0.248 us    |            test_ti_thread_flag();
>  3)   0.844 us    |          }
>  3)   1.341 us    |        }
>  3)   1.837 us    |      }
>  3)   0.275 us    |	   _spin_lock();
>  3)   0.257 us    |	   page_add_file_rmap();
>  3)   0.233 us    |      native_set_pte_at();

and /proc/kallsysms to be internationalized? Should all oopses 
and warnings that show up in the kernel log be translated as 
well?

I dont think it's realistic - and arguing for anything less and 
singling out tracing would be a double standard.

Currently being able to understand and hack the kernel means 
being able to read some English - and the same holds for trace 
output as well.

The default output of traces is just a mirror image of what is 
the kernel status quo. If the kernel gets internationalized so 
will ftrace be internationalized too.

> > So if you're arguing against specific ftrace plugins, go 
> > ahead (you probably have a fair point there). But please 
> > don't dismiss the while _concept_ of ftrace because of them.
> 
> Where on earth did that come from?
> 
> What I'm arguing against is putting English-only 
> pretty-printers and pretty-parsers on wrong side of int 80.  
> That's all.

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?

	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/