[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170904104717.rs4tuazdhtjvueac@pd.tnic>
Date: Mon, 4 Sep 2017 12:47:17 +0200
From: Borislav Petkov <bp@...en8.de>
To: mark gross <mgross@...ux.intel.com>,
Steven Rostedt <rostedt@...dmis.org>
Cc: Tony Luck <tony.luck@...el.com>,
linux-edac <linux-edac@...r.kernel.org>,
Yazen Ghannam <Yazen.Ghannam@....com>, X86 ML <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Mauro Carvalho Chehab <mchehab@...radead.org>
Subject: Re: [PATCH 0/7] EDAC, mce_amd: Issue decoded MCE through the
tracepoint
On Sun, Sep 03, 2017 at 04:37:04PM -0700, mark gross wrote:
> > 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."
Right, as I said to Mark earlier:
"Yeah, the moment something starts using it, it is ABI. The good thing
about it is, though, that it can get stuff appended to it, just like
tracepoints get fields added. And tools should be able to handle parsing
appended lines fine. Removing lines OTOH is always problematic. But
we'll make that append-only."
It is basically the same principle as with tracepoints where we can add
members easily.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Powered by blists - more mailing lists