Hi, Arthur Heymans wrote: > I would like to add a few notes to the meeting notes to clarify things a > bit better.
Thank you for that. > So the only thing not 'practical' here is that UEFI teams don't have > control over the handoff structure format that is inside coreboot and > is used by coreboot payloads (coreboot tables). Right. The spec (overview graphic) makes it clear that USF is an embrace-and-extend type of effort to supercede existing projects and de-facto standards in the space. > > The current payload handoff method has a number of flaws that > > they’d like to fix, such as the address for stack being hardcoded. > > Normally payloads set up their own stack very early on so this is not a > problem. It has always been a primary design goal for coreboot to leave no trace when the payload takes over. Payloads have total control of the system and need not look back. Anything that violates this principle goes against the primary design goal of coreboot to not stay resident. This primary design goal was very much on purpose. > The context here, was that I voiced some practical concerns about > using CBOR as a handoff structure. LinuxBIOS or coreboot tables were > carefully designed to be very easy to parse. 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. The same properties that make it technically unsuitable can of course make it a perfect choice politically, for someone. > My objection to a new format like cbor was that it is likely very hard to > parse using the same trampoline scheme. > It is likely possible to write a trampoline using a stack in C, but then > again that just complicates things a lot needlessly just to adopt a new > format with probably little to gain. I see zero gain for coreboot. The gain is political for someone outside of coreboot; using a free form and extensible data structure instead of coreboot tables moves handover standardization out of the coreboot project and enables arbitrary extension at will by someone not coreboot. I believe that would be a net loss for the firmware community at large. > > * The coreboot project can, however, encapsulate a CBOR-based > > handoff-structure into cbmem, similar to what we currently do > > with ACPI tables. > > I think this is about supporting both a CBOR-based handoff and coreboot > tables at the same time. > My concerns here are that is requires some synchronization between both > codepaths and just increases maintenance in general. > Introducing multiple codepaths to do roughly the same is an error we get > bit by way too often. I think we should be careful about this... Yes! Double trouble would be silly. If someone wants to use CBOR then why not just create a payload for that, rather than trying to mess up coreboot itself? > > Additionally Intel was willing to look at using CBOR structures as > > input and output to the FSP, so we could get rid of both the UPDs > > & HOBs. > > This seems like the real positive upshot of that conversation! 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. Kind regards //Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
