Hi all,
On 04.11.22 08:57, Arthur Heymans wrote:
So FDT has a few advantages over C structs for passing information between 2 separate programs:
- 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
- No need to be careful about ABI, writing structs e.g. 64bit alignment
this is something I've been seeing a lot during the whole universal payload discussions: The arguments often miss the point. These are actually good arguments. But they are about the implementation that handles the table data and not about the table format. One could describe the coreboot table data in some equivalent of FDT bindings and one could also write C structs for FDT bindings. 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 hope I'm using the terms right as I'm not yet used to FDT things.)
I agree with you that these, while nice, are not very compelling arguments
to replace coreboot tables, which are very established by now. For instance the header mismatch problem does not really exist given how stable coreboot tables have actually been. 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 :)
I think Intel only wanted to try FDT as an interface for FSP if it's also used in the payload (read EDK2) handoff (don't ask me why). Maybe someone needs to convince Intel that using FDT for just FSP is a good idea regardless of how payload handoff is handled.
They probably assume that FSP would talk to their payload directly with only a shim in between. Remember, the whole discussion started with somebody wanting to hand over HOBs to edk2 (which are currently produced by FSP).
And if we are going to talk about the special-purpose payload (I think that is what Intel means when they say `universal`) topic... one impor- tant point that was discussed at the OSFC was that we could have a neutral place to host the bindings (osfw.foundation was mentioned IIRC). So that Intel would have to agree to an interface that they couldn't dictate nor change whenever they like. IMO, this is the most important point of the whole endeavor.
If we can't get to some common ground there, we can still talk about FDT in coreboot. Although, IMHO, it would boil down to the simple question if we want to use FDT so we can use already written libraries and tools around it. Unless we wanted to replace ACPI with FDT¹ xD
So basically, 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'm not trying to stand in the way of experimenting with new alternatives if people want to do that.
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.
After all, I actually like the idea to use FDT. We just need to find a good use case for it :)
Nico
¹ I wouldn't mind that btw., replacing ACPI. Right now FDT seems to me like the better choice, it's just not what we have started with on x86. As it's less complex (not a programming language), assuming we'd gene- rate FDT info everywhere where we have ACPI now, it would be simple to write a compatibility layer, i.e. something that knows the FDT bindings we use and generates ACPI tables for them. Then one would only need ACPI in coreboot (or a shim payload?) if they want compatibility to OSs that don't understand FDT.