[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090225095623.GB12352@elte.hu>
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/
Powered by blists - more mailing lists