Julius Werner wrote:
- You said that coreboot tables were GPLv2 licensed, and this could
be an adoption problem for payloads...
The only generator code I know is GPLv2.
One could argue that only coreboot should ever generate this format, but I think one goal here is to enable or even encourage new situations.
I think the fundamental question here is still: what do we want to achieve, and how does replacing coreboot tables with something else help with that.
This isn't just a technical change, for me there is also the more political goal to make more of what Intel does with USF going forward (please see https://github.com/UniversalScalableFirmware/Introduction/blob/main/USF_Over... ) maximally useful for and within the coreboot context, ideally while encouraging reuse.
Since Intel has planned to use CBOR and are unlikely to use coreboot tables for anything outside of coreboot I see using FDT as a way to improve the situation for everyone while making players come together more - that's an unusually rare win-win.
I strongly prefer FDT over CBOR. FDT is simple on byte level, which I find important to not lose the simplicity of coreboot tables. FDT can easily be parsed without RAM, CBOR not so much.
use the same handoff format for FSP and the payload, What does that actually give us?
More common (data) patterns, more code re-use and potentially even some future innovation once common patterns are more broadly used.
ending up with a solution that's less suited for either target
I don't think FDT is less suited than coreboot tables where it matters the most - simplicity on byte level.
information that needs to be passed to the FSP is (according to my understanding, I'm admittedly not an FSP expert) completely different from the information that needs to be passed to the payload (except maybe for one or two tiny specks like console information?), so it's not like you'd actually want to reuse the actual data structure you built and pass both things the union of the stuff they each need to know, when the intersection of that is almost empty.
1. Already the possibility to maintain only a single dataset in a single format is quite nice, both conceptually and for usability.
2. Both of these software packages change over time, given the above possibility the intersection may expand.
The other aspect is the payload itself, and that whole "universal payload" idea (I assume that's what Intel is calling "USF" now, or is that something else?).
Please do look at the diagram on the last page of the USF PDF.
I think it makes clear what Intel is working towards.
The way we use payloads nowadays is often very deeply tied to coreboot,
More so if "often" means number of shipped systems, less so if "often" means the number of individual payloads.
You can't unify those things without unifying those implementations
Yes, but some compatibility is already a win in my opinion.
the extra cost of implementing a parser for a very simple, dependency-less handoff format like the coreboot tables is not really noticeable on top.
This is similar enough for coreboot tables and FDT, that's why I consider them really comparable.
That said, I understand Intel wants to push this
Intel wants to push USF and CBOR.
"Our" people want that energy to fit well with coreboot.
If we manage to improve some interfaces within UEFI in the process that would be even better.
can hopefully stay pretty isolated and self-contained in the code base
I think there should be just one source of truth, from which other formats are translated/derived.
I don't particularly care about CBOR vs FDT... I think both are pretty similar, both have tiny advantages and disadvantages for your goals, and both add a similarly large overhead compared to coreboot tables).
On the byte level only FDT and coreboot tables are really comparable.
I'd like to make sure that we can agree to keep coreboot tables as a first-class citizen now and in the future, and don't force a new format on anyone.
I don't think anyone proposed to not generate coreboot tables anymore.
Julius Werner wrote:
- reflection is easy
- no problem of 'header mismatch' to have the right definition of a struct
- easy to update with a text editor without needing to write code
Well, Arthur also admitted that none of these points are really relevant to coreboot's payload handoff, ;) which I fully agree with.
Currently that may be true, but reflection would pretty much be required for a new payload for manual parameter tweaking during boot.
(FWIW, I'm not aware of any instances where we broke coreboot table backwards compatibility in the past.)
I agree that coreboot tables have also been pretty stable.
Nico Huber wrote:
I've personally often argued for explicit serialization code instead of using C structs in coreboot. It's doable. In case of the coreboot tables, there's not that much benefit because the structs are well defined and make no trouble with alignment (compared to weird `packed` structs).
I think the most important improvement we could make to coreboot tables is to add explicit (de)serialization code, while others value reflection more. I agree however that reflection would create opportunity for new runtime UIs that are less doable or nonsensical without it.
As I understand it, cbtable member alignment is currently undefined. That matters when building firmware and payload with different compilers. "Just use the coreboot compiler" is not a good answer.
There is also no use case of wanting to edit the payload handoff by hand. At last x86 Linux can be launched in around 200 bytes of stackless assembly code... That's not possible with FDT or at least I'm not aware of any stackless assembly written FDT parser.
If there is no such thing yet, I'd argue to write a compiler for it. One that takes the bindings and a description where to put the data, and writes the assembler for you :)
Fun idea! It reminds me of romcc though.
Parsing FDT in assembler is anyway eminently doable, CBOR much less so.
Unless we wanted to replace ACPI with FDT¹ ¹ I wouldn't mind that btw., replacing ACPI.
That would be fantastic! But maybe it's more of a stretch goal. :)
Having multiple ways to do the same thing is a maintenance problem. It was a fun experiment, but it has no place in the master branch if the end goal is just to have FDT live side by side with coreboot tables.
Don't remember who said it. Somebody already said at the OSFC how a future could look like: We should keep the coreboot table for compati- bility in any case. We could freeze the format (structs) though and say new things should be described in FDT. But that would mean that we should keep two implementations in the tree, at least for a while. Alternatively, keep one in a shim layer payload. But that's still two things to maintain.
I talked a bit about the idea to have a single origin format and translation to other formats. Generic translators would not need much maintainance.
//Peter