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

[Frederic Weisbecker]

On Wed, Feb 25, 2009 at 10:56:23AM +0100, Ingo Molnar wrote:
> 
> * Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/