- 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.