Apr 1, 2022, 05:43 by pe...@stuge.se: > Arthur Heymans wrote: > >> 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. > 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.
If there is going to be a new, "universal" handoff method, my thought is that it's better for us to participate in that and try to influence it to be as usable as possible. If we have a chance to replace HOBs with something better, what's the best we can get? If CBOR isn't better, what is? >> 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. > Is there any suggestion for something better? We know that if Intel / UEFI want to update this, it's going to happen whether we want it or not. So how do we improve it? >> > * 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? > Sure, we can serialize this, make a translation layer for the cbtables to CBOR. It can be a coreboot option, or an intermediate payload. We decided that we didn't want to put all of the HOB creation code into coreboot itself, and we can do the same for whatever the next method is. If the FSP is going to use CBOR instead of UPDs, we'll already have the generation code in coreboot though, which isn't the case for the HOBs. We can currently read some HOBs, but to my knowledge, we don't generate any. > > >> > 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. > So maybe we try to limit the complexity? I'm not really familar with CBOR, so I don't know the issues with it. Intel did say that they were willing to look at other alternatives if we had any. If anyone has thoughts on alternatives, please suggest them. I hope nobody takes any of this as criticism - I appreciate the open discussion, and am sincerely looking for the best path forward here. Thanks, and take care. Martin _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
