[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YtUgb2Y/H/Wq9yIn@zn.tnic>
Date: Mon, 18 Jul 2022 10:57:19 +0200
From: Borislav Petkov <bp@...en8.de>
To: Yazen Ghannam <yazen.ghannam@....com>
Cc: linux-edac@...r.kernel.org, linux-kernel@...r.kernel.org,
tony.luck@...el.com, x86@...nel.org,
Smita.KoralahalliChannabasappa@....com
Subject: Re: [PATCH 1/3] x86/MCE, EDAC/mce_amd: Add support for new
MCA_SYND{1,2} registers
On Mon, Jul 11, 2022 at 05:31:41PM +0000, Yazen Ghannam wrote:
> Is your concern specifically on growing/changing struct mce, or is it more
> about limiting info sent to userspace?
Well, both, kinda.
> If it's the former, then I've been thinking it would be good to introduce a
> new internal "struct mce_ext" that includes struct mce plus other things. This
> way struct mce can still be uapi, and things like mcelog can use it. And at
> the same time we can new data used in the kernel or shared through
> tracepoints.
>
> /* Extended MCE structure */
> struct mce_ext {
> struct mce *m;
> /* new stuff here */
> };
>
> What do you think?
The moment you make it part of a trace record, it practically becomes
ABI.
So we could have some opaque blob which is called vendor-specific data
and which is dumped raw to userspace, without any specification to its
format so that luserspace doesn't get any ideas...
Lemme talk to rostedt.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists