Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

[Julius Werner <jwerner@chromium.org>]

> - fuller implementation with more features

Is that a good thing? Didn't we just have a long discussion eschewing
a heavy-handed, bulky hand-off block design in favor of more simple
and flexible structures? I think simplicity is key for this and the
bl_aux_params are trying to be about as simple as they can possibly
get. Particularly in a situation like this where many different
projects will need to implement this independently, any extra clutter
(like versioning, an apparently unused(?) flags field, checksumming)
adds unnecessary extra friction that's best to avoid. (You can *do*
all these things like adding an extra checksum over the whole thing
with bl_aux_params by just defining an extra tag for it, of course,
but none of them are required for platforms for which they don't make
sense.)

> - has comments / more documentation

Is there anything in particular you feel is missing from the
bl_aux_params comments?

> - easily supports everything in one block instead of a linked list (easier to allocate)

I don't understand how this is easier, in fact I see it as a big
drawback. The bl_aux_params design allows structures to be allocated
wherever -- in the easiest case you can just define them as global
variables in the earlier stage (in the respective files that deal with
each tag) and then chain those together. You *can* of course also
allocate them in a contiguous block from a special memory area, and if
you're planning to pass this across more than one stage boundary
that's probably the better choice. But not all platforms have that
requirement, and this design allows them the flexibility to choose.
The coreboot platforms only care about the BL2->BL31 transition, so
why should they switch to a design that forces us to set up an extra
contiguous-block allocator for no good reason?

> - avoids 64-bit tags/size which seem quite unnecessary

Well, earlier there were some concerns about possible tag collisions,
so I think the extra space doesn't hurt to alleviate those fears.
Having 64 bits allows us to split the tag space into many separate
ranges that can then be allocated from independently -- for example,
we could just say that the top 2^63 tags are available for private
vendor tags generated as random numbers (like a GUID). (Your bloblist
seems to waste space on things like a "spare" field instead, so in the
end both implementations still come out to the same overhead per tag,
and bloblist has additional overhead for the header at the front.)

> - ability to link to another bloblist (do we really need this?)

FWIW you can do this by default with bl_aux_params because they're not
required to be contiguous.