Okay, FWIW I created a pull request with my suggestions here: https://github.com/FirmwareHandoff/firmware_handoff/pull/4
That should make it easier to discuss specific details, hopefully. As I was looking at the header size and format more closely I noticed that the checksum calculation and some details about what the size fields mean seems underspecified right now, so I suggested a change for that as well. Let me know what you think.
One way to enforce that is for firmware components to refuse to accept a transfer list with unknown tags, assuming that all firmware is built from source at the same time. It might be a pain, but I suspect it could help avoid security problems, where bad actors use the structure to pass code to a firmware blob, etc.
I don't think that's feasible, particularly if tag IDs are not allocated in order (which I think is useful so that we can try to group similar tags by vendor, e.g. if say MediaTek wanted to add some tags they could just find some nice round number in the tag space, say 0x200, and then start allocating 0x201, 0x202, 0x203, etc. while the next vendor can do their own thing at 0x300 instead). It also creates automatic incompatibilities if you put newer and older components in the same image, which I think is something we explicitly don't want. I think the right policy to encourage compatibility is that unknown tags just get ignored.
I have to disagree here. The context is gone in this email, so I cannot reply to the comments there. But I think it was talking about using the transfer list for very tiny structures, just a few words. That is not the intent. Firstly we should really have TF-A use the device tree (embedded in the transfer list) instead of replicating bl_params in this structure. Secondly, we should group things into a C structure that is at least 16-32 bytes long.
Uhh... okay, sorry, but then you're going against everything that was discussed in this thread and in the previous discussions last year. The whole idea of making this a tagged list came from the argument that other structures (like FDT) are unnecessarily bulky and complex for some of the intended use cases (like replacing TF-A bl_aux_params). I mean, what's the point of even having a transfer list if all it does is wrap an FDT? You could just use the FDT directly! I think all the 4 tags that are currently specified in that document are pathological edge cases that may be necessary for legacy applications but represent the opposite of how this structure *should* be used in the ideal case. We don't need just more wrappers for the stuff that we already have, that doesn't promote interoperability in any way. If project A only wants to use HOBs but not FDT, and project B only wants to use FDT but not HOBs, then creating a transfer list structure that can wrap both an FDT and a HOB in a TE is pointless and not going to fix anything (project A will still not be able to parse the FDT-wrapping TE, and project B will still not be able to parse the HOB-wrapping TE). The only way this whole exercise can actually be useful and improve anything is if we can use it to eventually (slowly) get away from both HOBs and FDTs towards a point where all data is encoded in TEs directly, without any extra layers.
So I don't see a need for a smaller header. The 16-byte alignment works well with ACPI tables and we should not be using this structure for tiny things where the 8-byte overhead is significant.
FWIW, the compromise proposal now preserves the 16-byte TE alignment. (8 byte header, then small entries can use the next 8 bytes for data and the whole TE is only 16 bytes with only up to 7 bytes of forced padding. Once you need more than 8 bytes of data it gets a bit more ugly but at that point I guess you're not really a super small entry anymore.)