peter, you are right about CBOR, and that says to me it does not really meet the original goal of self-describing data. But coreboot tables, at least in my understanding, is also not self-describing.
Do you have some thoughts on a good format that is self-describing?
On Mon, Apr 11, 2022 at 3:05 PM Peter Stuge peter@stuge.se wrote:
Martin Roth via coreboot wrote:
Your concern is valid and I think a key point. CBOR may not be bad over a socket, but such a complex and arbitrarily extensible format is much too error prone to be a good technical choice during boot.
So if the idea is to create a payload handoff format that can be shared and used by multiple different firmware packages, do you have a better option? Yes, coreboot can just continue with just the coreboot tables, but that seems a little like sticking our head in the sand and refusing to recognize that other boot firmware exists.
I'd ask what other boot firmware is missing from coreboot tables for them to be universally acceptable.
I agree that it could be a step forward, but I think the devil is in the details. CBOR data structures can also be unneccessarily complex and error prone, beyond the parser itself.
So maybe we try to limit the complexity? I'm not really familar with CBOR, so I don't know the issues with it.
CBOR (RFC 8949) is a binary serialization of JSON with some extensions.
So "CBOR" itself says nothing about the data within.
Intel did say that they were willing to look at other alternatives if we had any.
That's a positive signal!
I propose that coreboot tables are a good alternative - fight me! :)
I hope nobody takes any of this as criticism - I appreciate the open discussion, and am sincerely looking for the best path forward here.
Not at all.
Let's see if coreboot tables can grow to cover all needs?
Kind regards
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org