lkml.org 
[lkml]   [2009]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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



\
 
 \ /
  Last update: 2009-02-25 17:25    [W:0.253 / U:0.152 seconds]
©2003-2014 Jasper Spaans. hosted at Digital Ocean