[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180228163539.GC2969@pd.tnic>
Date: Wed, 28 Feb 2018 17:35:39 +0100
From: Borislav Petkov <bp@...e.de>
To: "Ghannam, Yazen" <Yazen.Ghannam@....com>
Cc: Tony Luck <tony.luck@...el.com>,
"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"ard.biesheuvel@...aro.org" <ard.biesheuvel@...aro.org>,
"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH v2 0/8] Decode IA32/X64 CPER
On Wed, Feb 28, 2018 at 03:12:09PM +0000, Ghannam, Yazen wrote:
> CPER is the format used for BERT, etc. We'll only ever see a CPER if the
> firmware creates it. And it's up to firmware policy what is shared with
> the OS.
Yap, but we should still tie it into our infra.
> My main reason for printing all the info is that it may be too difficult or too
> late to gather that info after the fact. I think this is especially true for boot
> errors, though maybe there's another way that I don't know about
> (re-reading BERT later?).
So that BERT thing is a table, AFAIR. I don't see why it would be a
problem if we read it later, at our leisure and free the record only
when we're done.
Looking at bert.c is entered with a late_initcall() which is nicely late
and we have everything up and ready to process errors then.
> Right. I want to work on getting this more integrated with our existing
> x86 infrastructure. But I don't want to wait until we figure all that out
> before we have some sort of CPER decoding.
Just keep in mind that whenever you expose stuff and userspace starts
using it, it is much harder to change it. So let's do it right pls.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
Powered by blists - more mailing lists