[TF-A] [RFC] Proposed location to host the firmware handoff specification.

[Julius Werner]

Hi Jose,

Apologies for the late response, I had to find some time to dig back
into this topic first.

> The proposal is that the tag assignments are handled via a PR to [1].
> A PR should provide reasoning for the proposed entry layout as well as a description of the use-case being serviced.
> The community is invited to comment on the pull requests. We should aim to have community consensus before merging any PR.

I think this is a good approach if we understand "community consensus"
to be a quick, couple-of-days review cycle like we have for TF-A
patches that doesn't create a huge threshold for additions, and it's
fine for entries to be very specific to the needs of a single platform
when necessary. But I think the document should still have more
guidance about when standard vs. non-standard tags should be used, and
in particular just strongly discourage the use of non-standard tags in
general (basically I think they should only be used for experiments
that won't reach production code, or for cases where all code reading
or writing that tag is closed source). I think the spec should work
really hard in its language and guidance to discourage a situation
where firmware components just assign a non-standard tag to something
because it's easier and avoids the hassle of submitting something you
don't think you'd want to share at the time, and then later it becomes
entrenched and reused and eventually everyone has to pay attention to
not reuse the non-standard tags that accidentally acquired a fixed
meaning in enough implementations to become a problem. (It may also
make sense to just make the standard tag range much bigger than the
non-standard range, to make it clearer that the majority of things are
expected to go in there.)

> It seems sensible that data contained in an entry should not exceed 32MB.
> Could we still accommodate the notion of a hdr_size in the TL entry header?
> We'd have the following fields on an 8-byte TE header:
>   tag_id -- 4 bytes
>   hdr_size -- 1 byte
>   Data_size -- 3 bytes

Yeah, that seems like a reasonable compromise, if you really think
that variable header length is useful.

I still think the table header could be smaller as well (down to 16
bytes from 32 by just avoiding so much reserved space).

Do you want me to send those suggestions as pull requests to make them
easier to discuss?

> The document states that any tag in the standard range must be allocated in the spec before being used in code [4] -- what this is really saying is: until a tag id is allocated anyone can request it. So code written assuming a particular standard tag id (absent from the spec) may have to change later if someone in the meantime allocates that tag id for a different entry type.
> I believe it’s a per-community policy to prevent code submissions containing standard tag ids until these have been reserved in this spec.
> This is the advised policy, but this spec cannot mandate it, rather we must rely on the communities to enforce this.

I would say the spec should mandate that, honestly. If there is a
standardized range, no firmware implementing transfer lists according
to this spec should use tags from that range until they have been
defined in the global repository. On the flip side, we need to make
the process of defining new tags fast and painless so that this
requirement doesn't become a burden.

> For the current set of entries, the data is included within the TL. Note that this does not prevent newer entries from pointing to off-TL data.
> Could this be handled on a case-by-case basis, via pull request, after an initial full release of the spec?

Yes, we can leave it like this and later add tags for the off-list
equivalent of the tags defined there if necessary.