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: Tue, 15 Apr 2014 05:19:44 -0400 [thread overview]
Message-ID: <20140415091944.GB29868@gchen.bj.intel.com> (raw)
In-Reply-To: <20140414133924.GC3663@pd.tnic>
[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]
On Mon, Apr 14, 2014 at 03:39:24PM +0200, Borislav Petkov wrote:
> > +char *cper_mem_err_location(const struct cper_sec_mem_err *mem)
> > +{
> > + char *p;
> > + u32 n = 0;
> > +
> > + memset(mem_location, 0, CPER_REC_LEN);
> > + p = mem_location;
> > if (mem->validation_bits & CPER_MEM_VALID_NODE)
> > - pr_debug("node: %d\n", mem->node);
> > + n += sprintf(p + n, " node: %d", mem->node);
> > + if (n >= CPER_REC_LEN)
> > + goto end;
>
> n += vscnprintf(p + n, CPER_REC_LEN - n - 1, "... ", ...);
>
> and you can drop those
>
> if (n >= CPER_REC_LEN)
>
> tests.
>
> vscnprintf() because it returns the actual number of characters written
> and not what snprintf does and return the chars count it would've
> written. (Thx Richard for the hint!).
You are absolutely right. This function is perfect for this usage.
> > +char *cper_dimm_err_location(const struct cper_sec_mem_err *mem)
> > +{
> > + const char *bank = NULL, *device = NULL;
> > +
> > + memset(dimm_location, 0, CPER_REC_LEN);
> > + if (!(mem->validation_bits & CPER_MEM_VALID_MODULE_HANDLE))
> > + goto end;
>
> a goto label which is used only once?? What's wrong with
>
> return dimm_location;
>
I just feel repeating the same words looks ugly. OK, it is fine to me
to adopt your suggestion.
> > + dmi_memdev_name(mem->mem_dev_handle, &bank, &device);
> > + if (bank != NULL && device != NULL)
>
> if (bank && device)
>
> > + snprintf(dimm_location, CPER_REC_LEN - 1,
> > + "DIMM location: %s %s", bank, device);
> > + else
> > + snprintf(dimm_location, CPER_REC_LEN - 1, "DMI handle: 0x%.4x",
>
> Why the DMI handle? Why not say: "unable to find location" or "location
> not present in DMI" or something more user-friendly.
In essential, I use the suggestion from Tony Luck. DMI handle can't be found
so I just list the original info for it. Maybe I can merge them into one.
> > +#define CPER_REC_LEN 512
>
> How did we come up with this? Some spec? 512 chars for an error record?
> That's a bit too much in my book.
>
Because 128 is not enough once all fields in error record exist, and 256 looks
a little bit tough so I choose a bigger value. No spec for it. I just hope
it can contain everything.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2014-04-15 9:44 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 [this message]
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
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=20140415091944.GB29868@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).