From: "Chen, Gong" <gong.chen@linux.intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: tony.luck@intel.com, m.chehab@samsung.com, rostedt@goodmis.org,
linux-acpi@vger.kernel.org, arozansk@redhat.com
Subject: Re: [PATCH 2/5] CPER: Adjust code flow of some functions
Date: Wed, 16 Apr 2014 23:00:31 -0400 [thread overview]
Message-ID: <20140417030031.GA4303@gchen.bj.intel.com> (raw)
In-Reply-To: <20140416132818.GE16741@pd.tnic>
[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]
On Wed, Apr 16, 2014 at 03:28:18PM +0200, Borislav Petkov wrote:
> Yeah, we don't have to always adhere to the spec if we feel it doesn't
> make any sense. A lot of those fields above are purely useless and we
> shouldn't carry them blindly to the outside.
>
> For example, we don't need to carry cpu_brand[128] to the outside for
> *every* error. Who even came up with this crap, is beyond me??? It's
> like the cpu changes brand on every other error or what? You harvest
> this info only *once* from /proc/cpuinfo. cpu_version too. And so on and
> so on...
>
> Please sanity-check stuff like that before hardcoding it into the
> tracepoint. If it is in the spec it doesn't always mean it makes sense.
> We need to carry out only the minimum amount of information of each
> error which is actually getting used in userspace, for additional RAS
> actions. Carrying fat blobs just because the spec says so is simply
> wrong.
>
I agree. But at least for memory, I want to show them all. Maybe
requestor_id/responder_id/target_id are not so important. But in
reality, I've never seen they are valid. So just leave them there.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2014-04-17 3:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-28 5:52 Add new eMCA trace event interface Chen, Gong
2014-03-28 5:52 ` [PATCH 1/5] trace, RAS: Add basic RAS trace event Chen, Gong
2014-04-09 19:46 ` Borislav Petkov
2014-04-14 3:20 ` Chen, Gong
2014-04-14 10:46 ` Borislav Petkov
2014-04-16 6:33 ` Chen, Gong
2014-04-16 13:10 ` Borislav Petkov
2014-03-28 5:52 ` [PATCH 2/5] CPER: Adjust code flow of some functions Chen, Gong
2014-04-14 13:39 ` Borislav Petkov
2014-04-14 14:05 ` Borislav Petkov
2014-04-15 9:24 ` Chen, Gong
2014-04-15 18:02 ` Borislav Petkov
2014-04-16 5:01 ` Chen, Gong
2014-04-16 13:14 ` Borislav Petkov
2014-04-15 9:19 ` Chen, Gong
2014-04-15 18:05 ` Borislav Petkov
2014-04-16 6:23 ` Chen, Gong
2014-04-16 13:28 ` Borislav Petkov
2014-04-17 3:00 ` Chen, Gong [this message]
2014-03-28 5:52 ` [PATCH 3/5] trace, RAS: Add eMCA trace event interface Chen, Gong
2014-03-28 5:53 ` [PATCH 4/5] trace, eMCA: Add a knob to adjust where to save event log Chen, Gong
2014-04-03 23:46 ` Tony Luck
2014-04-04 8:05 ` Chen, Gong
2014-04-08 7:59 ` [PATCH 4/5 v2] " Chen, Gong
2014-03-28 5:53 ` [PATCH 5/5] trace, AER: Move trace into unified interface Chen, Gong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140417030031.GA4303@gchen.bj.intel.com \
--to=gong.chen@linux.intel.com \
--cc=arozansk@redhat.com \
--cc=bp@alien8.de \
--cc=linux-acpi@vger.kernel.org \
--cc=m.chehab@samsung.com \
--cc=rostedt@goodmis.org \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.