{% set rfcid = “RFC-0037” %} {% include “docs/contribute/governance/rfcs/_common/_rfc_header.md” %}
Note: Formerly known as FTP-037.
This proposal modifies the wire format as follows.
The reserved bytes of the transaction header are allocated to:
Additionally, rather than shoehorning epitaphs values in the header, an epitaph payload is a struct{int32}
.
Having a magic number in headers:
Having flags in headers:
On epitaph:
reserved
bytes, which are now used for the magic number and the flags;struct{int32}
removes one special snowflake from the wire format, which typically simplifies bindings and reduces the likelihood of bugs or incompatibilities.Lastly, we want to keep the header as small as possible, and it is an explicit goal to keep it at 16 bytes all the while supporting the additional requirements described above.
FIDL2 (“v2”):
uint32
)uint32
)uint32
)uint32
)uint32
)uint32
) OR Epitaph value (zx.status)uint32
)uint32
)uint32
)uint32
) OR Epitaph value (zx.status)uint64
)Initially, the reserved (uint32
) field covering bytes 4 through 7 was meant to align with requirements from zx_channel_call. However, the syscall has stabilized, and this requirement is no longer needed.
We stabilize the transactional message header (“v3”) to be:
uint32
)array<uint8>:3
, i.e. 3 bytes)uint8
)uint64
)Bindings MUST NOT check flags, except for specific flags these bindings are using or know about, i.e. it is valid to set a bit that is unknown to recipient bindings.
As a wire format diagram we have:
The initial magic number will be 0x01
. We reserve funnier numbers for later.
A magic number MUST be assigned to a new wire format when the wire format it is evolving or replacing cannot be reasonably phased out by the FIDL team.
Having epitaphs be struct{int32}
payloads, rather than embedded in the transaction header, increases the minimal amount of bytes read from 16 bytes to 24 bytes Performant bindings stack allocate a small buffer, and an increase of 8 bytes has minimal impact.