lkml.org 
[lkml]   [2009]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT PULL] tracing: Syscalls trace events + perf support
    On Tue, Aug 18, 2009 at 09:46:55AM +0900, Paul Mundt wrote:
    > [ Adding to Cc everyone that now has a broken tree thanks to this .. ]
    >
    > On Wed, Aug 12, 2009 at 11:11:33AM +0200, Ingo Molnar wrote:
    > > * Frederic Weisbecker <fweisbec@gmail.com> wrote:
    > > > This pull request integrate one cleanup/fix for ftrace and an
    > > > update for syscall tracing: the migration from old-style tracer to
    > > > individual tracepoints/trace_events and the support for perf
    > > > counter.
    > > >
    > > > I've tested it with success either with ftrace (every syscall
    > > > tracepoints enabled at the same time without problems) and with
    > > > perfcounter.
    > > >
    > > > May be one drawback: it creates so much trace events that the
    > > > ftrace selftests can take some time :-)
    > >
    > > Pulled, thanks a lot!
    > >
    > And this has now subsequently broken every single SH and S390
    > configuration, and anyone else unfortunate enough to be supporting ftrace
    > syscall tracing that isn't x86, without so much as a Cc, well done!
    >
    > The s390 case can be fixed up in-tree as support has already been merged,
    > but in the SH case we had ftrace syscall tracing queued up for 2.6.32, so
    > it doesn't show up in -tip, but the end result in -next is now completely
    > broken.
    >
    > I'm not sure how we should handle this, if tracing/core in -tip isn't
    > rebased, should I just pull the topic-branch in to my tree, fix up the sh
    > support on top of that, and push the end result out? This seems like the
    > easiest option at least, but I don't know what other dependencies exist
    > for tracing/core. Alternative suggestions welcome.
    >
    > This happens again and again with ftrace and -tip, where people just
    > randomly change existing interfaces, break all of the existing users, and
    > then fail to tell anyone about it until it shows up in -next. Even if we
    > had pushed all of the sh ftrace bits to the -tip tree early on it would
    > not have changed anything, evident by the fact that s390 and all of the
    > non ftrace syscall architectures were broken by this change as well (the
    > latter case was at least caught and corrected, although not by the
    > original authors of this patch series). Is it really that much to task
    > that people who are running around breaking ftrace interfaces actually
    > bother to Cc the architectures that are using it?



    I've just retrieved the concerned commit in the sh tree:

    sh: Add ftrace syscall tracing support (c652d780c9cf7f860141de232b37160fe013feca)

    Was I cc'ed on this one? I can't find it in my inbox. Unless I'm wrong
    and I missed it, how could I guess I had to cc you and how am I supposed
    to fix something I'm even not aware of?


    I can't find the s390 patch in my inbox either (was I cc'ed ?)
    ([S390] ftrace: add system call tracer support) but we should have fixed
    this one because it was already upstream and a git-grep ftrace_syscall_enter
    would have warned us about that.

    I didn't know another arch was supporting syscall tracing (except mips because
    I was cc'ed, but it doesn't seem upstream nor in the mips tree).


    >
    > If -tip is going to perpetuate this sort of half-assed development
    > methodology, it has no place in -next.



    \
     
     \ /
      Last update: 2009-08-18 12:27    [W:0.096 / U:0.764 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site