[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1278663285.1900.191.camel@laptop>
Date: Fri, 09 Jul 2010 10:14:45 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Paul Mackerras <paulus@...ba.org>
Cc: stephane eranian <eranian@...glemail.com>,
Robert Richter <robert.richter@....com>,
Will Deacon <will.deacon@....com>,
Paul Mundt <lethal@...ux-sh.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Cyrill Gorcunov <gorcunov@...il.com>,
Lin Ming <ming.m.lin@...el.com>,
Yanmin <yanmin_zhang@...ux.intel.com>,
Deng-Cheng Zhu <dengcheng.zhu@...il.com>,
David Miller <davem@...emloft.net>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 05/11] perf: register pmu implementations
On Fri, 2010-07-09 at 13:08 +1000, Paul Mackerras wrote:
> > -struct pmu *hw_perf_event_init(struct perf_event *event)
> > +static in sh_pmu_event_init(struct perf_event *event)
>
> int?
Argh, I fixed that a few times, but the hunk keeps slipping into
different patches.. cured.
> > {
> > int err = __hw_perf_event_init(event);
>
> We need a switch on event->attr.type so we return -ENOENT if it's
> not PERF_TYPE_{HARDWARE,HW_CACHE,RAW}. As it is we don't ever return
> -ENOENT, which might stop software and tracepoint events from working.
Aaah, indeed! That is why Matt's perf record broke, perf record defaults
to -e cycles which automagically falls back to a software timer, which
then doesn't work.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists