class VmoBuffer

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

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

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

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.

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.

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.

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

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

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