template <typename BuilderImpl>class WireTableBaseBuilder
Defined at line 8439 of file fidling/gen/sdk/fidl/fuchsia.sysmem2/fuchsia.sysmem2/cpp/fidl/fuchsia.sysmem2/cpp/wire_types.h
Public Methods
::fuchsia_sysmem2::wire::VmoBuffer Build ()Build and return the table. The builder should not be used after this.
bool has_vmo ()void clear_vmo ()Clears the vmo field.
This method should be used sparingly, such as only during tests, as it has
O(number_of_fields) complexity.
::zx::vmo & vmo ()`vmo` can be un-set if a participant has only
[`fuchsia.sysmem2/BufferUsage.none`] set to `NONE_USAGE` (explicitly or
implicitly by [`fuchsia.sysmem2/BufferCollection.SetConstraints`]
without `constraints` set).
BuilderImpl & vmo (::zx::vmo elem)`vmo` can be un-set if a participant has only
[`fuchsia.sysmem2/BufferUsage.none`] set to `NONE_USAGE` (explicitly or
implicitly by [`fuchsia.sysmem2/BufferCollection.SetConstraints`]
without `constraints` set).
bool has_vmo_usable_start ()void clear_vmo_usable_start ()Clears the vmo_usable_start field.
This method should be used sparingly, such as only during tests, as it has
O(number_of_fields) complexity.
uint64_t & vmo_usable_start ()Offset within the VMO of the first usable byte. Must be
<
the VMO's size
in bytes, and leave sufficient room for BufferMemorySettings.size_bytes
before the end of the VMO.
Currently sysmem will always set this field to 0, and in future, sysmem
won't set this field to a non-zero value unless all participants have
explicitly indicated support for non-zero vmo_usable_start (this
mechanism does not exist as of this comment). A participant that hasn't
explicitly indicated support for non-zero vmo_usable_start (all current
clients) should implicitly assume this field is set to 0 without
actually checking this field.
BuilderImpl & vmo_usable_start (Wrapper_Ignore_Me_< ::fidl::ObjectView<uint64_t>> elem)Offset within the VMO of the first usable byte. Must be
<
the VMO's size
in bytes, and leave sufficient room for BufferMemorySettings.size_bytes
before the end of the VMO.
Currently sysmem will always set this field to 0, and in future, sysmem
won't set this field to a non-zero value unless all participants have
explicitly indicated support for non-zero vmo_usable_start (this
mechanism does not exist as of this comment). A participant that hasn't
explicitly indicated support for non-zero vmo_usable_start (all current
clients) should implicitly assume this field is set to 0 without
actually checking this field.
bool has_close_weak_asap ()void clear_close_weak_asap ()Clears the close_weak_asap field.
This method should be used sparingly, such as only during tests, as it has
O(number_of_fields) complexity.
::zx::eventpair & close_weak_asap ()This field is set iff `vmo` is a sysmem weak VMO handle.
If the client sent `SetWeakOk`, the client must keep `close_weak_asap`
around for as long as `vmo`, and must notice `ZX_EVENTPAIR_PEER_CLOSED`.
If that signal occurs, the client must close `vmo` asap.
If the `vmo` is a sysmem weak VMO handle but the client didn't send
`SetWeakOk`, this means that a holder of a parent node sent `SetWeakOk`
with `for_child_nodes_also` true, and the owner of that parent node is
responsible for paying attention to `close_weak_asap` and informing
child token participants to close handles. In this case the participant
that never sent `SetWeakOk` is allowed to retain and/or pay attention to
`close_weak_asap` (to close the handle faster, or for other reasons such
as diagnosing overall buffer cleanup timing), but is not required to
retain or pay attention to `close_weak_asap`.
If sysmem closing the sysmem end of `close_weak_asap` does not result in
quick closure of all sysmem weak VMO handles to the buffer, that's
considered a VMO leak, and in that case sysmem will eventually complain
loudly via syslog (currently 5s later).
BuilderImpl & close_weak_asap (::zx::eventpair elem)This field is set iff `vmo` is a sysmem weak VMO handle.
If the client sent `SetWeakOk`, the client must keep `close_weak_asap`
around for as long as `vmo`, and must notice `ZX_EVENTPAIR_PEER_CLOSED`.
If that signal occurs, the client must close `vmo` asap.
If the `vmo` is a sysmem weak VMO handle but the client didn't send
`SetWeakOk`, this means that a holder of a parent node sent `SetWeakOk`
with `for_child_nodes_also` true, and the owner of that parent node is
responsible for paying attention to `close_weak_asap` and informing
child token participants to close handles. In this case the participant
that never sent `SetWeakOk` is allowed to retain and/or pay attention to
`close_weak_asap` (to close the handle faster, or for other reasons such
as diagnosing overall buffer cleanup timing), but is not required to
retain or pay attention to `close_weak_asap`.
If sysmem closing the sysmem end of `close_weak_asap` does not result in
quick closure of all sysmem weak VMO handles to the buffer, that's
considered a VMO leak, and in that case sysmem will eventually complain
loudly via syslog (currently 5s later).
Protected Methods
void WireTableBaseBuilder< ::fuchsia_sysmem2::wire::VmoBuffer, BuilderImpl> (::fidl::ObjectView< ::fidl::WireTableFrame< ::fuchsia_sysmem2::wire::VmoBuffer>> && frame)