Messages in this thread | | | Date | Wed, 25 Feb 2009 17:21:11 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 2/4] tracing: add event trace infrastructure |
| |
On Wed, Feb 25, 2009 at 10:56:23AM +0100, Ingo Molnar wrote: > > * Andrew Morton <akpm@linux-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.
Neither do I use the raw/bin formats from ftrace personally, but they are used by automated tools such as userspace side sysprof, blktrace, ...
Frederic.
> 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
| |