[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170628165514.kltemqgaxxhgw5as@pd.tnic>
Date: Wed, 28 Jun 2017 18:55:14 +0200
From: Borislav Petkov <bp@...e.de>
To: James Morse <james.morse@....com>
Cc: Xie XiuQi <xiexiuqi@...wei.com>,
Punit Agrawal <Punit.Agrawal@....com>,
"Baicar, Tyler" <tbaicar@...eaurora.org>, rostedt@...dmis.org,
ard.biesheuvel@...aro.org, bristot@...hat.com,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
zhengqiang10@...wei.com, shiju.jose@...wei.com, fu.wei@...aro.org,
wangxiongfeng2@...wei.com
Subject: Re: [PATCH v5] trace: ras: add ARM processor error information trace
event
On Wed, Jun 28, 2017 at 05:42:42PM +0100, James Morse wrote:
> > Alternatively, you can extend arm_event to get issued with *each*
> > cper_arm_err_info but that would mean a lot of redundant information
> > being shuffled out to userspace.
>
> I think this is what we should do,
Yes, that should be easier for userspace.
> but only keep the number of fields we export to a minimum. If we
> always use the names in the spec, and user-space always parses the
> 'format' file, we should be able to add more fields when they turn out
> to be necessary. (looks like the trace infrastructure makes inventing
> a new format easy!)
Right, except if you have userspace consumers already using them, you're
potentially breaking them. Unless you teach them all to parse the format
file first, from the very beginning. But in general, we try to be very
wary when touching tracepoints as they become an ABI of sorts.
Also, do try to shovel only the really needed info to userspace - not
everything the spec dumps but maybe just the fields that are really
necessary for doing hw error recovery.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
Powered by blists - more mailing lists