template <typename BuilderImpl>class WireTableBaseBuilder
Defined at line 5154 of file fidling/gen/sdk/fidl/fuchsia.sysmem2/fuchsia.sysmem2/cpp/fidl/fuchsia.sysmem2/cpp/wire_types.h
Public Methods
::fuchsia_sysmem2::wire::BufferMemoryConstraints Build ()Build and return the table. The builder should not be used after this.
bool has_min_size_bytes ()void clear_min_size_bytes ()Clears the min_size_bytes field.
This method should be used sparingly, such as only during tests, as it has
O(number_of_fields) complexity.
uint64_t & min_size_bytes ()un-set is treated as 1
BuilderImpl & min_size_bytes (Wrapper_Ignore_Me_< ::fidl::ObjectView<uint64_t>> elem)un-set is treated as 1
bool has_max_size_bytes ()void clear_max_size_bytes ()Clears the max_size_bytes field.
This method should be used sparingly, such as only during tests, as it has
O(number_of_fields) complexity.
uint64_t & max_size_bytes ()un-set is treated as 0xFFFFFFFFFFFFFFFF.
BuilderImpl & max_size_bytes (Wrapper_Ignore_Me_< ::fidl::ObjectView<uint64_t>> elem)un-set is treated as 0xFFFFFFFFFFFFFFFF.
bool has_physically_contiguous_required ()void clear_physically_contiguous_required ()Clears the physically_contiguous_required field.
This method should be used sparingly, such as only during tests, as it has
O(number_of_fields) complexity.
bool & physically_contiguous_required ()When false, physical pages of a buffer VMO can be non-contiguous. When
true, physical pages of a buffer VMO must be sequentially contiguous. A
client that doesn't require physically contiguous VMOs must still accept
physically contiguous VMOs or "physical" VMOs.
BuilderImpl & physically_contiguous_required (bool elem)When false, physical pages of a buffer VMO can be non-contiguous. When
true, physical pages of a buffer VMO must be sequentially contiguous. A
client that doesn't require physically contiguous VMOs must still accept
physically contiguous VMOs or "physical" VMOs.
bool has_secure_required ()void clear_secure_required ()Clears the secure_required field.
This method should be used sparingly, such as only during tests, as it has
O(number_of_fields) complexity.
bool & secure_required ()If true, the participant requires secure memory.
When aggregating `BufferCollectionConstraints`, these values boolean-OR.
BuilderImpl & secure_required (bool elem)If true, the participant requires secure memory.
When aggregating `BufferCollectionConstraints`, these values boolean-OR.
bool has_cpu_domain_supported ()void clear_cpu_domain_supported ()Clears the cpu_domain_supported field.
This method should be used sparingly, such as only during tests, as it has
O(number_of_fields) complexity.
bool & cpu_domain_supported ()When true (or when `BufferMemoryConstraints` is not present), the
participant is ok with sysmem selecting the CPU domain.
If the CPU domain is selected, participants must ensure the CPU can read
or write data to the buffer without cache operations outside of the
participant.
In other words, if a producer participant DMAs data directly to RAM on a
non-cache-coherent architecture such as arm, the producer must ensure
the CPU cache is clean wrt. the buffer before the DMA write, and
invalidate the CPU cache after the DMA write and before indicating that
the buffer is ready to any other participant. If a consumer participant
DMAs data directly from RAM on a non-cache-coherent architecture such as
arm, the consumer must flush the CPU cache wrt the buffer before the DMA
read.
CPU-only participants that don't do any DMA can just write and read the
buffers (when they should) without needing to do any CPU cache ops.
BuilderImpl & cpu_domain_supported (bool elem)When true (or when `BufferMemoryConstraints` is not present), the
participant is ok with sysmem selecting the CPU domain.
If the CPU domain is selected, participants must ensure the CPU can read
or write data to the buffer without cache operations outside of the
participant.
In other words, if a producer participant DMAs data directly to RAM on a
non-cache-coherent architecture such as arm, the producer must ensure
the CPU cache is clean wrt. the buffer before the DMA write, and
invalidate the CPU cache after the DMA write and before indicating that
the buffer is ready to any other participant. If a consumer participant
DMAs data directly from RAM on a non-cache-coherent architecture such as
arm, the consumer must flush the CPU cache wrt the buffer before the DMA
read.
CPU-only participants that don't do any DMA can just write and read the
buffers (when they should) without needing to do any CPU cache ops.
bool has_ram_domain_supported ()void clear_ram_domain_supported ()Clears the ram_domain_supported field.
This method should be used sparingly, such as only during tests, as it has
O(number_of_fields) complexity.
bool & ram_domain_supported ()When true, the participant is ok with sysmem selecting the RAM domain.
If the RAM domain is selected, producer data must be available in RAM
(with CPU cache state such that the RAM data won't get corrupted by a
dirty CPU cache line writing incorrect data to RAM), and a consumer
reading using the CPU must invalidate CPU cache before reading (the
producer doesn't guarantee zero stale "clean" cache lines).
In other words, if a producer participant uses the CPU to write data on
a non-cache-coherent architecture such as arm, the producer must flush
the data to RAM before indicating to another participant that the buffer
is ready. If a consumer participant uses the CPU to read data on a
non-cache-coherent architecture such as arm, the participant must
invalidate (typically flush+invalidate with knowledge that no cache
lines are dirty) the CPU cache before reading the buffer.
RAM-only participants that don't do any CPU accesses to a buffer can
just do DMA to/from the buffers (when they should) without needing to
do any CPU cache ops.
BuilderImpl & ram_domain_supported (bool elem)When true, the participant is ok with sysmem selecting the RAM domain.
If the RAM domain is selected, producer data must be available in RAM
(with CPU cache state such that the RAM data won't get corrupted by a
dirty CPU cache line writing incorrect data to RAM), and a consumer
reading using the CPU must invalidate CPU cache before reading (the
producer doesn't guarantee zero stale "clean" cache lines).
In other words, if a producer participant uses the CPU to write data on
a non-cache-coherent architecture such as arm, the producer must flush
the data to RAM before indicating to another participant that the buffer
is ready. If a consumer participant uses the CPU to read data on a
non-cache-coherent architecture such as arm, the participant must
invalidate (typically flush+invalidate with knowledge that no cache
lines are dirty) the CPU cache before reading the buffer.
RAM-only participants that don't do any CPU accesses to a buffer can
just do DMA to/from the buffers (when they should) without needing to
do any CPU cache ops.
bool has_inaccessible_domain_supported ()void clear_inaccessible_domain_supported ()Clears the inaccessible_domain_supported field.
This method should be used sparingly, such as only during tests, as it has
O(number_of_fields) complexity.
bool & inaccessible_domain_supported ()When true, the participant is ok with sysmem selecting the INACCESSIBLE
domain.
If the INACCESSIBLE domain is selected, CPU reads and writes of the data
are prevented. Attempts to read/write the data with the CPU may result
in UB and/or process termination.
If the INACCESSIBLE domain is selected, participants must only operate
on the data using DMAs performed by HW, or platform-specific DMA-like
requests to a secure environment (which will do the needed CPU cache ops
similar to how a RAM domain participant would operate).
Secure heaps only support INACCESSIBLE domain, and will fail allocation
if any participant with `BufferUsage` other than `NONE_USAGE` does not
set inaccessible_domain_supported to true.
When the INACCESSIBLE domain is selected, participants (outside of
secure/DRM environments) should not attempt to map buffers, and should
not attempt to perform any CPU cache ops. In this respect, this domain
is similar to RAM domain with all participants only doing DMA and no
participant(s) doing CPU accesses.
BuilderImpl & inaccessible_domain_supported (bool elem)When true, the participant is ok with sysmem selecting the INACCESSIBLE
domain.
If the INACCESSIBLE domain is selected, CPU reads and writes of the data
are prevented. Attempts to read/write the data with the CPU may result
in UB and/or process termination.
If the INACCESSIBLE domain is selected, participants must only operate
on the data using DMAs performed by HW, or platform-specific DMA-like
requests to a secure environment (which will do the needed CPU cache ops
similar to how a RAM domain participant would operate).
Secure heaps only support INACCESSIBLE domain, and will fail allocation
if any participant with `BufferUsage` other than `NONE_USAGE` does not
set inaccessible_domain_supported to true.
When the INACCESSIBLE domain is selected, participants (outside of
secure/DRM environments) should not attempt to map buffers, and should
not attempt to perform any CPU cache ops. In this respect, this domain
is similar to RAM domain with all participants only doing DMA and no
participant(s) doing CPU accesses.
bool has_permitted_heaps ()void clear_permitted_heaps ()Clears the permitted_heaps field.
This method should be used sparingly, such as only during tests, as it has
O(number_of_fields) complexity.
::fidl::VectorView< ::fuchsia_sysmem2::wire::Heap> & permitted_heaps ()Which heaps are acceptable to the participant. Participants that don't
care which heap memory is allocated on should leave this field un-set. A
secure heap is only selected if all participants explicitly indicate
that the secure heap is acceptable via `heap_permitted`, or specify
`NONE_USAGE`.
BuilderImpl & permitted_heaps (Wrapper_Ignore_Me_< ::fidl::ObjectView< ::fidl::VectorView< ::fuchsia_sysmem2::wire::Heap>>> elem)Which heaps are acceptable to the participant. Participants that don't
care which heap memory is allocated on should leave this field un-set. A
secure heap is only selected if all participants explicitly indicate
that the secure heap is acceptable via `heap_permitted`, or specify
`NONE_USAGE`.
Protected Methods
void WireTableBaseBuilder< ::fuchsia_sysmem2::wire::BufferMemoryConstraints, BuilderImpl> (::fidl::ObjectView< ::fidl::WireTableFrame< ::fuchsia_sysmem2::wire::BufferMemoryConstraints>> && frame)