On Tue, Feb 27, 2018 at 03:25:06PM +0000, Ghannam, Yazen wrote:
> This is the same as the other CPER code.
Dude, turn on brain!
So if it is in the other CPER code, we should copy it, no matter how
dumb it is?!?
> Also, the spec allows platform-defined GUIDs. So we should always print this
> even if the GUID is not defined by the spec.
We need to have a way to map the GUID to a hw part. Dumb numbers mean shit
because the error record is worthless.
> The Check Information will be decoded further in another patch.
>
> I don't think there's much else to decode for the ID fields.
Again, those numbers can't help decoding the error, no need to dump
them. Or we find a way to make sense out of that info.
> Other tables may have the same fields but the offsets are usually different.
> So it may be more trouble than it's worth trying to unify the different tables.
If the structs are the same, you can use generic functions for dumping -
the offsets are meaningless then.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
