[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87lhxnl261.fsf@ashishki-desk.ger.corp.intel.com>
Date: Fri, 07 Feb 2014 11:09:26 +0200
From: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To: Andi Kleen <andi@...stfloor.org>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
Frederic Weisbecker <fweisbec@...il.com>,
Mike Galbraith <efault@....de>,
Paul Mackerras <paulus@...ba.org>,
Stephane Eranian <eranian@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>,
Matt Fleming <matt.fleming@...el.com>
Subject: Re: [PATCH v1 09/11] x86: perf: intel_pt: Add core dump functionality
Andi Kleen <andi@...stfloor.org> writes:
> Alexander Shishkin <alexander.shishkin@...ux.intel.com> writes:
>> +
>> +static void pt_trace_core_output(struct coredump_params *cprm,
>> + struct perf_event *event,
>> + unsigned long len)
>> +{
>> + struct pt_buffer *buf;
>> + u64 from, to;
>> + int ret;
>> +
>> + buf = itrace_priv(event);
>> +
>> + if (!dump_emit(cprm, pt_pmu.capstr, pt_pmu.caplen))
>> + return;
>
> It would be nicer if this was a separate note, instead of just being
> concatenated with the rest of the data.
>
> Would make simpler parsing and be cleaner.
So long as we won't have to include traces from two different pmus in
the same core file, then matching these sections may provide another
challenge. Doesn't seem like a sensible scenario, though.
Regards,
--
Alex
--
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