[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170628133855.65509c93@gandalf.local.home>
Date: Wed, 28 Jun 2017 13:38:55 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Borislav Petkov <bp@...e.de>
Cc: James Morse <james.morse@....com>, Xie XiuQi <xiexiuqi@...wei.com>,
Punit Agrawal <Punit.Agrawal@....com>,
"Baicar, Tyler" <tbaicar@...eaurora.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, 28 Jun 2017 18:55:14 +0200
Borislav Petkov <bp@...e.de> wrote:
> > 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.
No no. You can add new fields easily. There should be no breakage, as
the userspace tools should be using the traceevent library code. It
only breaks when you remove a field. Which reminds me, I really need to
get that out into distros *this* year. I've been putting this off for
far too long.
The ras tool has its own copy of the traceevent library parser.
-- Steve
>
> 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.
>
Powered by blists - more mailing lists