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    [from the cache]
    ©2003-2011 Jasper Spaans