From: mark gross <mgross@linux.intel.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Borislav Petkov <bp@alien8.de>, Tony Luck <tony.luck@intel.com>,
linux-edac <linux-edac@vger.kernel.org>,
Yazen Ghannam <Yazen.Ghannam@amd.com>, X86 ML <x86@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Mauro Carvalho Chehab <mchehab@infradead.org>
Subject: Re: [PATCH 0/7] EDAC, mce_amd: Issue decoded MCE through the tracepoint
Date: Sun, 3 Sep 2017 16:37:04 -0700 [thread overview]
Message-ID: <20170903233704.GC90926@mtgdev> (raw)
In-Reply-To: <20170830193058.00740c87@gandalf.local.home>
On Wed, Aug 30, 2017 at 07:30:58PM -0400, Steven Rostedt wrote:
> On Wed, 30 Aug 2017 14:47:19 -0700
> mark gross <mgross@linux.intel.com> wrote:
>
>
> > > struct dentry *ras_debugfs_dir;
> > >
> > > static atomic_t trace_count = ATOMIC_INIT(0);
> > > @@ -12,7 +14,9 @@ EXPORT_SYMBOL_GPL(ras_userspace_consumers);
> > >
> > > static int trace_show(struct seq_file *m, void *v)
> > > {
> > > - return atomic_read(&trace_count);
> > > + seq_printf(m, "readers:%d\n", atomic_read(&trace_count));
> > > + seq_printf(m, "has decoder:%d\n", mca_cfg.has_decoder);
> >
> > do you want to worry about this debugfs interfaces as ABI?
>
> It's the old, if a tree falls in the forest issue. If you break the ABI
> but nobody is around to notice, did it really break?
perhaps, but what I was trying to point out was: "multi line debugFS printf's
like this are very easy to change to append other information and you might
want to worry about the ABI implications that could happen in the future."
--mark
>
> > debugfs changes have bitten me on one specific OS in irritating ways.
> >
> > I'm not sure what the word is for debugfs interfaces as ABI these days so this
> > feedback may be not so useful.
>
> I discussed this with Boris before he sent it out. The current code is
> actually broken. The trace_show() looks to be just a stub for a hack to
> have userspace tell the kernel it's reading something (the
> trace_count). The trace_show() function here returns the trace_count,
> which is just wrong. The seq_file show function is suppose to return
> less than zero on error, zero on success, or greater than zero if the
> show is suppose to skip the current field but not error out. This
> trace_show() function doesn't actually show anything. If you cat the
> file, it will be blank. Returning zero or greater than zero has the
> same effect. Which is nothing.
>
> -- Steve
> --
> To unsubscribe from this list: send the line "unsubscribe linux-edac" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-09-03 23:37 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-25 10:24 [PATCH 0/7] EDAC, mce_amd: Issue decoded MCE through the tracepoint Borislav Petkov
2017-08-25 10:24 ` [PATCH 1/7] x86/mce: Handle an in-kernel MCE decoder Borislav Petkov
2017-08-25 10:24 ` [PATCH 2/7] x86/mce: Extend the MCE tracepoint with a decoded string Borislav Petkov
2017-08-25 10:24 ` [PATCH 3/7] seq_buf: Add seq_buf_clear_buf() Borislav Petkov
2017-08-25 10:24 ` [PATCH 4/7] seq_buf: Export seq_buf_printf() to modules Borislav Petkov
2017-08-25 13:27 ` Steven Rostedt
2017-08-25 10:24 ` [PATCH 5/7] EDAC, mce_amd: Convert to seq_buf Borislav Petkov
2017-08-25 13:30 ` Steven Rostedt
2017-08-25 10:24 ` [PATCH 6/7] EDAC, mce_amd: Issue the decoded info through the TP or printk() Borislav Petkov
2017-08-25 13:33 ` Steven Rostedt
2017-08-25 10:24 ` [PATCH 7/7] x86/mce: Issue the mcelog --ascii message on !AMD Borislav Petkov
2017-08-28 13:45 ` [PATCH 0/7] EDAC, mce_amd: Issue decoded MCE through the tracepoint Borislav Petkov
2017-08-30 11:48 ` Borislav Petkov
2017-08-30 21:47 ` mark gross
2017-08-30 22:02 ` Borislav Petkov
2017-08-31 19:17 ` Borislav Petkov
2017-08-30 23:30 ` Steven Rostedt
2017-09-03 23:37 ` mark gross [this message]
2017-09-04 10:47 ` Borislav Petkov
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=20170903233704.GC90926@mtgdev \
--to=mgross@linux.intel.com \
--cc=Yazen.Ghannam@amd.com \
--cc=bp@alien8.de \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/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