lkml.org 
[lkml]   [2012]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT PULL] tracing: make signal tracepoints more useful
    On 01/16, Ingo Molnar wrote:
    >
    > * Steven Rostedt <rostedt@goodmis.org> wrote:
    >
    > > On Mon, 2012-01-16 at 08:45 +0100, Ingo Molnar wrote:
    > >
    > > > Looks good to me at a first (quick) sight, except this bit
    > > > which changes the ABI:
    > > >
    > > > > > - TP_printk("sig=%d errno=%d code=%d comm=%s pid=%d",
    > > > > > + TP_printk("sig=%d errno=%d code=%d comm=%s pid=%d grp=%d res=%d",
    > > >
    > > > That's not how we change tracepoints generally - we add a new
    > > > one and eventually phase out the old one. Which apps/tools rely
    > > > on the old tracepoint? If it's exactly zero apps then we might
    > > > be able to change it, but this needs to be investigated.
    > >
    > > But this tracepoint wasn't changed, it was added on to.
    > > There's a difference. Any tool that uses this (including
    > > something like powertop) should be able to handle it. [...]
    >
    > That's mostly true in theory - the question is, is it true in
    > practice?
    >
    > Say if an app relies on the smaller data structure, it sure
    > might get surprised by the kernel writing a wider record ...

    OK, I am not arguing, I'll resend the patch which adds the new
    tracepoint...

    But do we really need to keep the old tracepoint? IOW, what if
    we simply rename it and add more info?

    I am looking at "git log include/trace/events/", for example
    "mm-tracepoint: rename page-free events" b413d48a.

    Oleg.



    \
     
     \ /
      Last update: 2012-01-16 16:19    [W:0.030 / U:30.796 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site