ron minnich wrote:
> My goal was pretty simple: Kill the UEFI HOBs, and the FSP UPD, and
> put something better in their place. coreboot tables could easily
> replace HOBs, save that intel will never accept that;

Thanks, now I understand.


> but I don't see coreboot tables replacing UPD.

Why couldn't they? (Politics aside, for now.)


> I like self describing data as it avoids that mess that we are in with
> UPD today, where you can end up with problems if the compilers you use
> for FSP and (e.g.) coreboot don't agree totally on how to lay out data
> structures.

Understand! Not even having a well-defined serialization is a disaster.
CBOR is a solution to that but I think it has way too many primitives.


> UPD are also a major pain for non-C firmware, such as oreboot.

Again because of undefined alignment, or something else?


> So I'd like a data format that is not defined by a compiler or
> language. But maybe I'm the only person who wants that :-)

I completely agree that well-defined serialization is neccessary for
interoperability, it's pretty amazing that Intel overlooked that.
I wonder what else..


You asked about other serializations, the one I was last pleasantly
surprised by was the Kafka protocol, which isn't as arduous as
one might think based on the name. :) Like coreboot tables it does
not describe structure, only values, so reader and writer must agree
on what they transfer out-of-band based on a shared definition, but
certainly not based on any compiler properties.

It is however a network and disk serialization - far simpler than
CBOR but maybe still unneccessarily complex or at least somewhat
unfitting for firmware. It mostly has signed values and later
versions (there's a version in a header) add varints to save bytes,
because the protocol is made for very high message volume - so not
really applicable to firmware.


How about using cbtable primitives to express UPD and calling it
something new?


//Peter
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to