[docs] Completed //docs update to fix go/which-that issues
Change-Id: I8e0c386977736715ee35db0487244b19d70657d8
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/482977
Fuchsia-Auto-Submit: Rich Kadel <richkadel@google.com>
Commit-Queue: Auto-Submit <auto-submit@fuchsia-infra.iam.gserviceaccount.com>
Reviewed-by: Nick Van der Auwermeulen <nickvander@google.com>
diff --git a/docs/reference/diagnostics/consumers/iquery.md b/docs/reference/diagnostics/consumers/iquery.md
index 9329730..af812f7 100644
--- a/docs/reference/diagnostics/consumers/iquery.md
+++ b/docs/reference/diagnostics/consumers/iquery.md
@@ -65,7 +65,7 @@
### `list-files [<paths...>]`
-Lists all files which contain inspect data under the given `paths`. This will
+Lists all files that contain inspect data under the given `paths`. This will
only list files for v1 components given that v2 components are not mapped to the
filesystem at the moment.
diff --git a/docs/reference/diagnostics/consumers/log_listener.md b/docs/reference/diagnostics/consumers/log_listener.md
index 15c327338..f6e6f01c 100644
--- a/docs/reference/diagnostics/consumers/log_listener.md
+++ b/docs/reference/diagnostics/consumers/log_listener.md
@@ -1,6 +1,6 @@
# log_listener CLI
-The `log_listener` binary is included in all device builds which include `pkgfs` and is currently
+The `log_listener` binary is included in all device builds that include `pkgfs` and is currently
the primary tool used by engineers to interactively read a live log stream. In-tree developers
usually invoke it with [`fx log`](https://fuchsia.dev/reference/tools/fx/cmd/log).
diff --git a/docs/reference/diagnostics/inspect/updating-vmo-format.md b/docs/reference/diagnostics/inspect/updating-vmo-format.md
index 5e21a8e..612f26c 100644
--- a/docs/reference/diagnostics/inspect/updating-vmo-format.md
+++ b/docs/reference/diagnostics/inspect/updating-vmo-format.md
@@ -185,7 +185,7 @@
1. Update the actual reader in [/zircon/system/ulib/inspect/reader.cc][reader-cc]:
1. Update `InnerScanBlocks` to dispatch your type.
If you are creating a new Property, you may only have to add your `BlockType`.
- 1. If you need a custom parser, implement `InnerParseMyFoo` which takes
+ 1. If you need a custom parser, implement `InnerParseMyFoo`, which takes
a parent (if needed) and the pointer to the scanned block.
### Implement tests {#implement-tests}
diff --git a/docs/reference/diagnostics/inspect/validator/README.md b/docs/reference/diagnostics/inspect/validator/README.md
index d0e5df4..2dc1a12 100644
--- a/docs/reference/diagnostics/inspect/validator/README.md
+++ b/docs/reference/diagnostics/inspect/validator/README.md
@@ -7,7 +7,7 @@
* A set of tests to validate functionality.
* A FIDL protocol to invoke operations to be tested.
-* One or more puppet programs which receive FIDL commands and invoke library
+* One or more puppet programs, which receive FIDL commands and invoke library
calls.
* A reference implementation or simulation of the desired behavior.
* Analysis of puppet results, comparison to local results, and reporting.
diff --git a/docs/reference/diagnostics/inspect/validator/puppet.md b/docs/reference/diagnostics/inspect/validator/puppet.md
index f2e7887..e47c94a 100644
--- a/docs/reference/diagnostics/inspect/validator/puppet.md
+++ b/docs/reference/diagnostics/inspect/validator/puppet.md
@@ -3,7 +3,7 @@
## Overview
The Validator program sends FIDL commands to control a "puppet" program, which
-invokes library functionality to modify some state which the Validator then
+invokes library functionality to modify some state that the Validator then
evaluates. For more information about the Inspect Validator, see the
[README](README.md).
@@ -32,7 +32,7 @@
## Serving FIDL
The `main()` function performs boilerplate to serve a single FIDL client
-through `run_driver_service()` which receives either `Initialize` or `Act`
+through `run_driver_service()`, which receives either `Initialize` or `Act`
events from the FIDL stream. `Act` events are unpacked by the `Actor` object
which maintains the state necessary to control the Inspect library.
@@ -64,21 +64,21 @@
### Dependencies and names
[Validator's BUILD.gn file](/src/diagnostics/validator/inspect/BUILD.gn#21)
-defines a `validator_bin` target which is used by the
+defines a `validator_bin` target, which is used by the
[Rust puppet's BUILD.gn file](/src/diagnostics/validator/inspect/lib/rust/BUILD.gn#33)
as a dependency to the `test_package()` named `inspect_validator_test_rust`
which is the test that exercises the Rust puppet.
The Rust puppet itself is
[built as a standard rustc_binary](/src/diagnostics/validator/inspect/lib/rust/BUILD.gn#10).
-That build rule produces two names, `inspect_validator_rust_puppet_bin` which
+That build rule produces two names, `inspect_validator_rust_puppet_bin`, which
is included in the deps of the `test_package()` rule, and
-`inspect_validator_rust_puppet` which is included in the binaries of the
+`inspect_validator_rust_puppet`, which is included in the binaries of the
`test_package()`.
The `validator_bin` target from the
[Validator's Build.gn file](/src/diagnostics/validator/inspect/BUILD.gn#21)
-has a name of `validator` which is referred to in the `tests` of the
+has a name of `validator`, which is referred to in the `tests` of the
`test_package()`.
### CQ/CI
diff --git a/docs/reference/diagnostics/logs/access.md b/docs/reference/diagnostics/logs/access.md
index 740ce83..30b5757b 100644
--- a/docs/reference/diagnostics/logs/access.md
+++ b/docs/reference/diagnostics/logs/access.md
@@ -146,7 +146,7 @@
A message with dropped logs in the errors may or may not have a `payload` associated, depending on
where the message was dropped.
-When a producing component overflows its log socket, it increments a counter which is used on
+When a producing component overflows its log socket, it increments a counter that is used on
subsequent successful sends to populate a field in the log metadata. The Archivist tracks this
metadata but isn't able to learn about a component dropping log records except through later log
records from that component. The metadata is passed on to clients in the same form, as an error
@@ -158,7 +158,7 @@
## Legacy APIs
-Archivist serves the `fuchsia.logger.Log` protocol which allows clients to read logs in a text
+Archivist serves the `fuchsia.logger.Log` protocol that allows clients to read logs in a text
format. This API is superceded by `fuchsia.diagnostics.ArchiveAccessor` and will be deleted in the
future.
diff --git a/docs/reference/fidl/bindings/go-bindings.md b/docs/reference/fidl/bindings/go-bindings.md
index 4bdc3185..ce91714 100644
--- a/docs/reference/fidl/bindings/go-bindings.md
+++ b/docs/reference/fidl/bindings/go-bindings.md
@@ -339,7 +339,7 @@
nullable response value. This is considered un-idiomatic, you should use an [error type](#protocols-results)
instead.
-FIDL generates a `TicTacToeWithCtx` interface which is used by clients when
+FIDL generates a `TicTacToeWithCtx` interface, which is used by clients when
proxying calls to the server, and by the server for implementing the protocol:
```golang
@@ -397,7 +397,7 @@
`TicTacToeWithCtxInterface` provides methods for handling events:
* `func (p *TicTacToeWithCtxInterface) ExpectOnOpponentMove(ctx_ fidl.Context)
- (GameState, error)`: Event handler for `OnOppponentMove` which takes a
+ (GameState, error)`: Event handler for `OnOppponentMove`, which takes a
`Context` and returns the event parameters.
Calling any of the event handler methods will read the next buffered event or
@@ -483,7 +483,7 @@
#### Transitional {#transitional}
In order to support the `[Transitional]` attribute in Go, FIDL generates a
-`TicTacToeWithCtxTransitionalBase` type which provides default implementations
+`TicTacToeWithCtxTransitionalBase` type, which provides default implementations
for every method marked as `[Transitional]`. Server implementations that embed
`TicTacToeWithCtxTransitionalBase` will continue to build a new transitional
method is added.
diff --git a/docs/reference/fidl/bindings/hlcpp-bindings.md b/docs/reference/fidl/bindings/hlcpp-bindings.md
index 9186d5c..81adad1 100644
--- a/docs/reference/fidl/bindings/hlcpp-bindings.md
+++ b/docs/reference/fidl/bindings/hlcpp-bindings.md
@@ -186,7 +186,7 @@
[Flexible][lang-flexible] enums are implemented as a `class` instead of an `enum
class`, with the following methods:
-* `constexpr LocationType()`: Default constructor which initializes the enum to
+* `constexpr LocationType()`: Default constructor, which initializes the enum to
an unspecified unknown value.
* `constexpr LocationType(uint32_t value)`: Explicit constructor that takes in a
value of the underlying type of the enum.
@@ -263,7 +263,7 @@
Each member of `Tag` has a value matching its [ordinal][union-lexicon] specified
in the `union` definition. Reserved fields do not have any generated code. In
-addition, there is an `Invalid` field which is the initial value used for a
+addition, there is an `Invalid` field, which is the initial value used for a
`JsonValue` that has no variant set yet.
`JsonValue` provides the following methods:
@@ -327,7 +327,7 @@
`JsonValue::Ordinal()` returns the unknown ordinal.
A flexible `JsonValue` type will have extra methods for interacting with unknown
-data which will depend on whether the type is a
+data that will depend on whether the type is a
[value or resource type][lang-resource]. Value types will not have
unknown data methods that reference `zx::handle`.
@@ -438,7 +438,7 @@
instead.
FIDL generates a `TicTacToe` class, which acts as an entry point for interacting
-with the protocol and defines the interface of the service which is used by
+with the protocol and defines the interface of the service used by
clients to proxy calls to the server, and for the server for implementing the
protocol. Synchronous clients use a different virtual interface, `TicTacToe_Sync`.
diff --git a/docs/reference/fidl/bindings/llcpp-bindings.md b/docs/reference/fidl/bindings/llcpp-bindings.md
index b6e55e6..20cec4a 100644
--- a/docs/reference/fidl/bindings/llcpp-bindings.md
+++ b/docs/reference/fidl/bindings/llcpp-bindings.md
@@ -155,7 +155,7 @@
Flexible enums are implemented as a `class` instead of an `enum class`, with the
following methods:
-* `constexpr LocationType()`: Default constructor which initializes the enum to
+* `constexpr LocationType()`: Default constructor, which initializes the enum to
an unspecified unknown value.
* `constexpr LocationType(uint32_t value)`: Explicit constructor that takes in a
value of the underlying type of the enum.
@@ -422,7 +422,7 @@
##### Creation
A client is created with a client-end `zx::channel`, an `async_dispatcher_t*` and an optional
-shared pointer on an [`AsyncEventHandler`](#async-event-handlers) which defines the methods to be
+shared pointer on an [`AsyncEventHandler`](#async-event-handlers) that defines the methods to be
called when a FIDL event is received or when the client is unbound. If the virtual for a particular
event is not overriden, the event is ignored.
@@ -465,7 +465,7 @@
Note: If you shutdown the dispatcher while there are any active bindings, the
unbound hook may be executed on the thread executing shutdown. As such, you must
-not take any locks which could be taken by hooks provided to `fidl::Client` APIs
+not take any locks that could be taken by hooks provided to `fidl::Client` APIs
while executing `async::Loop::Shutdown()/async_loop_shutdown()`. (You should
probably ensure that no locks are held around shutdown anyway since it joins all
dispatcher threads, which may take locks in user code).
@@ -812,7 +812,7 @@
* `virtual Unbound(::fidl::UnbindInfo info) {}`: method called when the client has been unbound.
-To be able to handle events and unbound, a class which inherits from `AsyncEventHandler` must be
+To be able to handle events and unbound, a class that inherits from `AsyncEventHandler` must be
defined.
#### Sync client {#sync-event-handlers}
@@ -829,7 +829,7 @@
The status to be returned by `HandleOneEvent` if an unknown event is found.
This method should be overriden only if a specific status is needed.
-To be able to handle events, a class which inherits from `SyncEventHandler` must be
+To be able to handle events, a class that inherits from `SyncEventHandler` must be
defined. This class must define the virtual methods for the events it wants to handle. All the
other events are ignored. Then an instance of this class must be allocated.
@@ -859,7 +859,7 @@
##### Sending events using a server binding object {#bound-event-sending}
When binding a server implementation to a channel, calling `fidl::BindServer`
-will return a `fidl::ServerBindingRef<Protocol>` which is the means by which you
+will return a `fidl::ServerBindingRef<Protocol>`, which is the means by which you
may interact safely with a server binding. This class allows access to an event
sender interface through the following operators:
@@ -1061,7 +1061,7 @@
the case of all the secondary objects. That means that the provided buffer must
be kept alive while the decoded value is used.
-For FIDL types which allow handles, the handles can be specified during
+For FIDL types that allow handles, the handles can be specified during
construction after the bytes (the same way bytes are specified).
### Persistence
diff --git a/docs/reference/fidl/bindings/rust-bindings.md b/docs/reference/fidl/bindings/rust-bindings.md
index b64be09..00745ea 100644
--- a/docs/reference/fidl/bindings/rust-bindings.md
+++ b/docs/reference/fidl/bindings/rust-bindings.md
@@ -65,7 +65,7 @@
type `T`, the [proxied function call](#protocols-client) does not need to take
ownership of `T` so the FIDL toolchain needs to generate a borrowed version of
`T`. Borrowed versions often use `&mut` since the type `T` may contain handles,
-in which case the FIDL bindings zero out the handles when encoding which
+in which case the FIDL bindings zero out the handles when encoding, which
modifies the input. Using `&mut` instead of taking ownership allows callers to
reuse the input value if it does not contain handles.
@@ -486,7 +486,7 @@
* `make_move(&mut self, mut row: u8, mut col: u8, __deadline: zx::Time) ->
Result<(bool, Option<Box<GameState>>), fidl::Error>`: Proxy method for a two
way method. It takes the request parameters as arguments followed by a
- deadline parameter which dictates how long the method call will wait for a
+ deadline parameter, which dictates how long the method call will wait for a
response (or `zx::Time::INFINITE` to block indefinitely). It returns a
`Result` of the [response parameters](#request-response-event-parameters).
@@ -518,7 +518,7 @@
#### Request responder {#request-responder}
-Each two way method has a corresponding generated responder type which the
+Each two way method has a corresponding generated responder type, which the
server uses to respond to a request. In this example, which only has one two way
method, the FIDL toolchain generates `TicTacToeMakeMoveResponder`, which
provides the following methods:
diff --git a/docs/reference/fidl/language/bindings-spec.md b/docs/reference/fidl/language/bindings-spec.md
index 8cdf533..b5e9b81 100644
--- a/docs/reference/fidl/language/bindings-spec.md
+++ b/docs/reference/fidl/language/bindings-spec.md
@@ -28,7 +28,7 @@
user-defined symbols. This can be implement using scoping constructs provided by
the language, like namespaces in C++, modules in Rust, or packages in Go and
Dart. If the generated scope can have a name, it SHOULD be named using
-components of the FIDL library name which contains the definitions for the
+components of the name of the FIDL library that contains the definitions for the
generated code, which allows each FIDL library to exist in a unique scope. In
cases where scoping is not possible and the namespace is shared, some processing
of the generated names (see [Naming](#naming)) may be necessary.
@@ -99,7 +99,7 @@
* bitwise exclusive-or, i.e `^`
* bitwise not, i.e `~`
-To provide bitwise operations which always result in valid bits values,
+To provide bitwise operations that always result in valid bits values,
implementations of bitwise not should further mask the resulting value with the
mask of all values. In pseudo code:
@@ -407,7 +407,7 @@
"linearization"). The downside of such an approach is that it makes the bindings
more rigid: changes to the FIDL wire format become more complex to implement.
-The [LLCPP bindings][llcpp] are the only binding which take this
+The [LLCPP bindings][llcpp] are the only binding that take this
approach.
### Equality comparison
diff --git a/docs/reference/fidl/language/fidlc.md b/docs/reference/fidl/language/fidlc.md
index 322abaa..72e5816 100644
--- a/docs/reference/fidl/language/fidlc.md
+++ b/docs/reference/fidl/language/fidlc.md
@@ -15,8 +15,8 @@
its constructor. This class exposes a `Lex()` method, which returns the next [`Token`](#token)
in the file; it can be called repeatedly to get the sequence of `Token`s in the file.
3. The compiler uses the `Lexer` to initialize a [`Parser`](#parsing) and then calls the `Parse()`
- method which constructs a parse tree. The code refers to parse trees as a raw AST. This function
- returns a `raw::File` which is the class representing the root node of the raw AST.
+ method, which constructs a parse tree. The code refers to parse trees as a raw AST. This function
+ returns a `raw::File`, which is the class representing the root node of the raw AST.
4. Once the compiler has parsed each file into a parse tree, it then groups the parse trees into a
single AST (referred to in the code as a flat AST) for each library. The root of this flat AST
is a `flat::Library`.
@@ -26,12 +26,12 @@
`flat::Constant`. The converted `flat::` AST nodes are then stored under a single
`flat::Library`. Initially these flat AST nodes contain the same information as the raw AST
nodes, but they also contain fields such as a `value` field for values and a `typeshape` field
- for types which are later set during the compilation step.
+ for types that are later set during the compilation step.
5. Once the AST has been fully initialized, the compiler evaluates constants and determines the
memory alignment and size information for the declared types.
Note: One of the key distinction between raw and flat ASTs is that each raw tree represents a
-single file, whereas each flat tree represents a single FIDL library which may contain multiple
+single file, whereas each flat tree represents a single FIDL library that may contain multiple
files.
Finally, we end up with a flat AST that is processed and ready for backend generation either to C
@@ -150,7 +150,7 @@
}
```
-The method starts by creating a new `ASTScope` which initializes the `SourceElement` that will
+The method starts by creating a new `ASTScope`, which initializes the `SourceElement` that will
later be used to create the returned node by pushing it onto `active_ast_scopes_`. The start of
the `SourceElement` gets set to the first token that is consumed and the end gets set in the call
to `GetSourceElement()` before returning.
@@ -316,7 +316,7 @@
gets set during compilation.
`TypeDecl`s representing an aggregate type (e.g. structs, tables, and unions) also
-have a static `Shape()` method which contains the logic for determining the `Typeshape`
+have a static `Shape()` method, which contains the logic for determining the `Typeshape`
of that given type.
### FieldShape {#fieldshape}
@@ -338,7 +338,7 @@
### SourceFile {#sourcefile}
-Wrapper around a file which is responsible for owning the data in that file. Also see [Virtual
+Wrapper around a file, which is responsible for owning the data in that file. Also see [Virtual
SourceFile](#virtualsourcefile)
### SourceLocation {#sourcelocation}
@@ -357,9 +357,9 @@
`location_` attribute), enhanced with two other pieces information that are useful to the parser
during the later stages of compilation:
-* `previous_end_`. A `SourceLocation` which starts at the end of the previous token and ends at the
+* `previous_end_`. A `SourceLocation`, which starts at the end of the previous token and ends at the
start of this token. It contains data that is uninteresting to the parser such as whitespace.
-* A kind and subkind which together classifies the lexeme. The possible kinds are:
+* A kind and subkind that, together, classify the lexeme. The possible kinds are:
* The special characters such as `Kind::LeftParen`, `Kind::Dot`, `Kind::Comma`, etc...
* String and numeric constants
* Identifiers. Tokens that are keywords (e.g. `const`, `struct`) are considered identifiers, but
@@ -371,8 +371,8 @@
A struct representing an instance of a type. For example, the `vector<int32>:10?` type corresponds
to an instance of the `VectorType` `TypeDecl` with `max_size_ = 10` and `maybe_arg_type` set to the
-`Type` corresponding to `int32`. Built-in types all have a static `Shape()` method which will
-return the `Typeshape` given the parameters for an instance of that type. User defined types (e.g.
+`Type` corresponding to `int32`. Built-in types all have a static `Shape()` method that
+returns the `Typeshape` given the parameters for an instance of that type. User defined types (e.g.
structs or unions) will all have a type of `IdentifierType` - the corresponding
[`TypeDecl`](#typedecl), like `Struct` provides the static `Shape()` method instead.
diff --git a/docs/reference/fidl/language/grammar.md b/docs/reference/fidl/language/grammar.md
index b261b32..6a1a1b2 100644
--- a/docs/reference/fidl/language/grammar.md
+++ b/docs/reference/fidl/language/grammar.md
@@ -190,7 +190,7 @@
The `bits-or-enum-member-value` allows the more liberal `literal` in the grammar, but the compiler limits this to:
* A `NUMERIC-LITERAL` in the context of an `enum`;
-* A `NUMERIC-LITERAL` which must be a power of two, in the context of a `bits`.
+* A `NUMERIC-LITERAL`, which must be a power of two, in the context of a `bits`.
### NOTE 5
The `protocol-method` error stanza allows the more liberal `type-constructor`
diff --git a/docs/reference/fidl/language/language.md b/docs/reference/fidl/language/language.md
index eaa4b915..19af41a 100644
--- a/docs/reference/fidl/language/language.md
+++ b/docs/reference/fidl/language/language.md
@@ -186,7 +186,7 @@
Libraries may declare that they use other libraries with a "using" declaration.
This allows the library to refer to symbols defined in other libraries upon which
-they depend. Symbols which are imported this way may be accessed by:
+they depend. Symbols imported this way may be accessed by:
* qualifying them with the fully qualified library name (as in _"fuchsia.geometry.Rect"_),
* specifying just the library name (as in _"geometry.Rect"_), or,
@@ -206,7 +206,7 @@
For example, the C++ bindings generator places declarations for the
FIDL library "fuchsia.ui" within the C++ namespace
-"fuchsia::ui". Similarly, for languages such as Dart and Rust which
+"fuchsia::ui". Similarly, for languages such as Dart and Rust, which
have their own module system, each FIDL library is compiled as a
module for that language.
@@ -295,7 +295,7 @@
Arrays are denoted **`array<T>:n`** where _T_ can
be any FIDL type (including an array) and _n_ is a positive
-integer constant expression which specifies the number of elements in
+integer constant expression that specifies the number of elements in
the array.
```fidl
@@ -443,7 +443,7 @@
Here, we show how `Profile` evolves to also carry temperature units.
A client aware of the previous definition of `Profile` (without temperature units)
-can still send its profile to a server which has been updated to handle the larger
+can still send its profile to a server that has been updated to handle the larger
set of fields.
```fidl
@@ -502,7 +502,7 @@
* Structs always have strict behavior.
* Tables always have flexible behavior.
-For strict types only, serializing or deserializing a value which contains data
+For strict types only, serializing or deserializing a value that contains data
not described in the declaration is a validation error.
In this example:
@@ -514,7 +514,7 @@
By virtue of being flexible, it is simpler for `FlexibleEither` to evolve to
carry a third variant. A client aware of the previous definition of
`FlexibleEither` without the third variant can still receive a union from a
-server which has been updated to contain the larger set of variants. If the
+server that has been updated to contain the larger set of variants. If the
union is of the unknown variant, bindings may expose it as unknown data (i.e. as
raw bytes and handles) to the user and allow re-encoding the unknown union (e.g.
to support proxy-like use cases). The methods provided for interacting with
@@ -570,7 +570,7 @@
### Protocols {#protocols}
-* Describe methods which can be invoked by sending messages over a channel.
+* Describe methods that can be invoked by sending messages over a channel.
* Methods are identified by their ordinal index. The compiler calculates the ordinal by
* Taking the SHA-256 hash of the string generated by concatenating:
* The UTF-8 encoded library name, with no trailing \0 character
@@ -590,7 +590,7 @@
each invocation of the method generates a response from the server.
* If only results are declared, the method is referred to as an
*event*. It then defines an unsolicited message from the server.
- * Two-way methods may declare an error type which a server can send
+ * Two-way methods may declare an error type that a server can send
instead of the response. This type must be an `int32`, `uint32`, or an
`enum` thereof.
@@ -740,7 +740,7 @@
We may not necessarily wish to expose the more privileged `Horologist` protocol to just
any client, but we do want to expose it to the system clock component.
-So, we create a protocol (`SystemClock`) which composes both:
+So, we create a protocol (`SystemClock`) that composes both:
```fidl
{%includecode gerrit_repo="fuchsia/fuchsia" gerrit_path="examples/fidl/fuchsia.examples.docs/language_reference.test.fidl" region_tag="layering-systemclock" %}
diff --git a/docs/reference/fidl/language/wire-format/README.md b/docs/reference/fidl/language/wire-format/README.md
index 5bc3b23..906db27 100644
--- a/docs/reference/fidl/language/wire-format/README.md
+++ b/docs/reference/fidl/language/wire-format/README.md
@@ -97,10 +97,10 @@
During **encoding**...
-* All pointers to sub-objects within the message are replaced with flags which
+* All pointers to sub-objects within the message are replaced with flags that
indicate whether their referent is present or not-present,
* All handles within the message are extracted to an associated **handle
- vector** and replaced with flags which indicate whether their referent is
+ vector** and replaced with flags that indicate whether their referent is
present or not-present.
The resulting **encoded message** and **handle vector** can then be sent to
@@ -485,7 +485,7 @@
* `txid`s with the high bit set are reserved for use by
[**zx_channel_write()**][channel write]
* `txid`s with the high bit unset are reserved for use by userspace
- * A value of `0` for `txid` is reserved for messages which do not
+ * A value of `0` for `txid` is reserved for messages that do not
require a response from the other side.
Note: For more details on `txid` allocation, see
[**zx_channel_call()**][channel call].
@@ -533,7 +533,7 @@
The server sends method response messages to the client to indicate completion
of a method invocation and to provide a (possibly empty) result.
-Only two-way method requests which are defined to provide a (possibly empty) result
+Only two-way method requests that are defined to provide a (possibly empty) result
in the protocol declaration will elicit a method response.
One-way method requests must not produce a method response.
@@ -609,14 +609,14 @@
`alignof(T)` denotes the alignment factor in bytes to store an object of type **T**.
-FIDL primitive types are stored at offsets in the message which are a multiple
+FIDL primitive types are stored at offsets in the message that are a multiple
of their size in bytes. Thus for primitives **T**, `alignof(T) ==
sizeof(T)`. This is called *natural alignment*. It has the
nice property of satisfying typical alignment requirements of modern CPU
architectures.
FIDL complex types, such as structs and arrays, are stored at offsets in the
-message which are a multiple of the maximum alignment factor of all of their
+message that are a multiple of the maximum alignment factor of all of their
fields. Thus for complex types **T**, `alignof(T) ==
max(alignof(F:T))` over all fields **F** in **T**. It has the nice
property of satisfying typical C structure packing requirements (which can be
@@ -627,8 +627,8 @@
FIDL primary and secondary objects are aligned at 8-byte offsets within the
message, regardless of their contents. The primary object of a FIDL message
starts at offset 0. Secondary objects, which are the only possible referent of
-pointers within the message, always start at offsets which are a multiple of 8.
-(So all pointers within the message point at offsets which are a multiple of 8.)
+pointers within the message, always start at offsets that are a multiple of 8.
+(So all pointers within the message point at offsets that are a multiple of 8.)
FIDL in-line objects (complex types embedded within primary or secondary
objects) are aligned according to their type. They are not forced to 8 byte
diff --git a/docs/reference/kernel/kernel_cmdline.md b/docs/reference/kernel/kernel_cmdline.md
index dacf91c..7979964 100644
--- a/docs/reference/kernel/kernel_cmdline.md
+++ b/docs/reference/kernel/kernel_cmdline.md
@@ -43,7 +43,7 @@
Controls blobfs' eviction strategy for pager-backed blobs with no open handles or
VMO clones. If unset, an internally defined system default is used.
-Blobs which are not pager-backed are not affected by this knob.
+Blobs that are not pager-backed are not affected by this knob.
The following values are supported:
@@ -806,7 +806,7 @@
"any", in which case the first volume of the appropriate type will be used.
"local" in which the first volume that's non-removable of the appropriate type
will be used.
-"none" (default) which avoids mounting anything.
+"none" (default), which avoids mounting anything.
A "/system" ramdisk provided by bootdata always supersedes this option.
@@ -852,7 +852,7 @@
`lsdev` command on the ethernet class device (e.g., `/dev/class/ethernet/000`).
This is useful for configuring network booting for a device with multiple
-ethernet ports which may be enumerated in a non-deterministic order.
+ethernet ports, which may be enumerated in a non-deterministic order.
## netsvc.all-features=\<bool>
diff --git a/docs/reference/kernel_objects/clock.md b/docs/reference/kernel_objects/clock.md
index 74bc559..1c619f0 100644
--- a/docs/reference/kernel_objects/clock.md
+++ b/docs/reference/kernel_objects/clock.md
@@ -8,7 +8,7 @@
A clock is a one dimensional affine transformation of the
[clock monotonic](/docs/reference/syscalls/clock_get_monotonic.md) reference
-timeline which may be atomically adjusted by a clock maintainer, and observed by
+timeline, which may be atomically adjusted by a clock maintainer, and observed by
clients.
## DESCRIPTION
@@ -22,11 +22,11 @@
When set, the clock is guaranteed to have monotonic behavior. This is to say
that any sequence of observations of the clock is guaranteed to produce a
-sequence of times which are always greater than or equal to the previous
+sequence of times that are always greater than or equal to the previous
observations. A monotonic clock can never go backwards, although it _can_ jump
forwards. Formally:
-Given a clock _C_, Let C(x) be the function which maps from the reference
+Given a clock _C_, Let C(x) be the function that maps from the reference
timeline _C's_ timeline. C(x) is a piecewise linear function made up of all the
affine transformation segments over all time as determined by _C's_ maintainer.
_C_ is monotonic if and only if:
@@ -52,7 +52,7 @@
The backstop time of a clock represents the minimum value that a clock may ever
be set to. Since clocks can only tick forwards, and never backwards, it is
-impossible for an observer of a clock to ever receive a value which is less than
+impossible for an observer of a clock to ever receive a value that is less than
the backstop time configured by a clock's creator.
A backstop time may be provided via the `zx_create_args_v1_t` structure at
@@ -60,7 +60,7 @@
During clock update operations, any attempt to set the clock's value to
something less than the backstop time will fail with **ZX_ERR_INVALID_ARGS**. A
-clock which has not been initially set will always report the backstop time
+clock that has not been initially set will always report the backstop time
configured for the clock. Backtop times may never be less than the default
value of zero.
@@ -124,7 +124,7 @@
clock.
+ The last time the clock was updated as defined by the clock monotonic
reference timeline.
-+ An observation of the system tick counter which was taken during the
++ An observation of the system tick counter, which was taken during the
observation of the clock.
+ All of the static properties of the clock defined at creation time.
+ A generation nonce.
@@ -156,7 +156,7 @@
will begin running at that point with a rate equal to the reference clock plus
the deviation from nominal specified by the maintainer.
-Clocks also have a **ZX_CLOCK_STARTED** signal which may be used by users to
+Clocks also have a **ZX_CLOCK_STARTED** signal, which may be used by users to
know when the clock has actually been started. Initially, this signal is not
set, but it becomes set after the first successful update operation. Once
started, a clock will never stop and the **ZX_CLOCK_STARTED** signal will always
@@ -170,7 +170,7 @@
configured backstop time.
If a clock is created with the **ZX_CLOCK_OPT_AUTO_START** options, it cannot be
-configured with a backstop time which is greater than the current clock
+configured with a backstop time that is greater than the current clock
monotonic time. If this was allowed, this would result in a state where a
clock's current time is set to a time before its backstop time.
@@ -215,7 +215,7 @@
The level of confidence in this estimate is _not_ specified by the kernel APIs.
It is possible that some clock maintainers are using a strict bound, while
-others are using a bound which is not provable but provides "high confidence",
+others are using a bound that is not provable but provides "high confidence",
while others still might have little to no confidence in their estimates.
In the case that a user needs to understand the objective quality of the error
diff --git a/docs/reference/kernel_objects/futex.md b/docs/reference/kernel_objects/futex.md
index 55e45db..28ca904 100644
--- a/docs/reference/kernel_objects/futex.md
+++ b/docs/reference/kernel_objects/futex.md
@@ -7,7 +7,7 @@
## SYNOPSIS
A **futex** is a Fast Userspace muTEX. It is a low level
-synchronization primitive which is a building block for higher level
+synchronization primitive that is a building block for higher level
APIs such as `pthread_mutex_t` and `pthread_cond_t`.
Futexes are designed to not enter the kernel or allocate kernel
@@ -43,7 +43,7 @@
address of an aligned userspace integer. This virtual address is the
information used in kernel to track what futex given threads are
waiting on. The kernel does not currently modify the value of
-`*value_ptr` (but see below for future operations which might do
+`*value_ptr` (but see below for future operations that might do
so). It is up to userspace code to correctly atomically modify this
value across threads in order to build mutexes and so on.
@@ -54,7 +54,7 @@
Futex objects do not have any rights associated with them.
-There are only 2 primitive operations which userspace code can perform on a
+There are only 2 primitive operations that userspace code can perform on a
futex: waiting and waking (requeue is a combination of the two). Because
futexes are strictly a process local concept, revoking access to either of these
operations would make the futex functionally worthless.
@@ -96,7 +96,7 @@
Signaling of the owner of a futex is the responsibility of the userspace code,
as is applying the ownership concept properly when constructing a specific type
-of synchronization object which needs priority inheritance behavior.
+of synchronization object that needs priority inheritance behavior.
Zircon futexes have at most a single owner. Multiple ownership of futexes for
the purpose of priority inheritance is not supported. The owner of a futex may
@@ -112,12 +112,12 @@
+ Passing a valid handle to a thread to indicate the futex owner is the
responsibility of the userspace code. Passing an invalid handle, or a handle
to a non-thread object will result in the wait/requeue operation failing.
-+ Threads which have not been started yet may not own a futex. Any attempt to
- assign ownership of a futex to a thread which has not yet been started will
++ Threads that have not been started yet may not own a futex. Any attempt to
+ assign ownership of a futex to a thread that has not yet been started will
result in the wait/requeue operation failing.
-+ Threads which have exited may not be the owner of a futex. If a thread exits
++ Threads that have exited may not be the owner of a futex. If a thread exits
while it owns a futex, the futex will reset to being owned by no one. If a
- user attempts assign ownership of a futex to a thread which has exited, the
+ user attempts assign ownership of a futex to a thread that has exited, the
wait/requeue operation will behave as if ZX_HANDLE_INVALID had been passed as
the new futex owner.
+ If the wait/requeue operation succeeds, the owner of the target futex will
diff --git a/docs/reference/kernel_objects/objects.md b/docs/reference/kernel_objects/objects.md
index 8c6b131..b5630c1 100644
--- a/docs/reference/kernel_objects/objects.md
+++ b/docs/reference/kernel_objects/objects.md
@@ -59,10 +59,10 @@
## Kernel object lifetime
Kernel objects are ref-counted. Most kernel objects are born during a syscall
-and are held alive at refcount = 1 by the handle which binds the handle value
+and are held alive at refcount = 1 by the handle, which binds the handle value
given as the output of the syscall. The handle object is held alive as long it
is attached to a handle table. Handles are detached from the handle table
-closing them (for example via `sys_close()`) which decrements the refcount of
+closing them (for example via `sys_close()`), which decrements the refcount of
the kernel object. Usually, when the last handle is closed the kernel object
refcount will reach 0 which causes the destructor to be run.
diff --git a/docs/reference/kernel_objects/pager.md b/docs/reference/kernel_objects/pager.md
index d13bf78..3eff8f9 100644
--- a/docs/reference/kernel_objects/pager.md
+++ b/docs/reference/kernel_objects/pager.md
@@ -22,10 +22,10 @@
VMOs can be differentiated by the *key* parameter used when creating the VMO. It is also possible
for multiple independent pager objects to exist simultaneously.
-Creating a pager is not a privileged operation. However, the default behavior of syscalls which
+Creating a pager is not a privileged operation. However, the default behavior of syscalls that
operate on VMOs is to fail if the operation would require blocking on IPC back to a userspace
process, so applications generally need to be aware of when they are operating on pager owned
-VMOs. This means that services which provide pager owned VMOs to clients should be explicit about
+VMOs. This means that services that provide pager owned VMOs to clients should be explicit about
doing so as part of their API. Whether or not accesses into a VMO may result in a pager request
can be determined by checking for the **ZX_INFO_VMO_PAGER_BACKED** flag returned by
[`zx_object_get_info()`] in `zx_info_vmo_t`.
diff --git a/docs/reference/kernel_objects/process.md b/docs/reference/kernel_objects/process.md
index dff41d1..2b6b0f3 100644
--- a/docs/reference/kernel_objects/process.md
+++ b/docs/reference/kernel_objects/process.md
@@ -7,7 +7,7 @@
## SYNOPSIS
A zircon process is an instance of a program in the traditional
-sense: a set of instructions which will be executed by one or more
+sense: a set of instructions that will be executed by one or more
threads, along with a collection of resources.
## DESCRIPTION
@@ -18,7 +18,7 @@
+ [Virtual Memory Address Regions](vm_address_region.md)
+ [Threads](thread.md)
-In general, it is associated with code which it is executing until it is
+In general, it is associated with code, which it is executing until it is
forcefully terminated or the program exits.
Processes are owned by [jobs](job.md) and allow an application that is
diff --git a/docs/reference/kernel_objects/resource.md b/docs/reference/kernel_objects/resource.md
index dc5eadb..93427fa 100644
--- a/docs/reference/kernel_objects/resource.md
+++ b/docs/reference/kernel_objects/resource.md
@@ -23,7 +23,7 @@
**ZX_RSRC_KIND_ROOT**, **ZX_RSRC_KIND_MMIO**, **ZX_RSRC_KIND_IOPORT**,
**ZX_RSRC_KIND_IRQ**, **ZX_RSRC_KIND_SMC**, and **ZX_RSRC_KIND_SYSTEM**.
-The system resource is a special case which contains other resources which all have *len*
+The system resource is a special case that contains other resources, all of which have *len*
one. These resources each have their own base within the system resource. Valid *base*
values for the system resource are **ZX_RSRC_SYSTEM_HYPERVISOR_BASE**,
**ZX_RSRC_SYSTEM_VMEX_BASE**, **ZX_RSRC_SYSTEM_DEBUG_BASE**,**ZX_RSRC_SYSTEM_INFO_BASE**,
diff --git a/docs/reference/kernel_objects/thread.md b/docs/reference/kernel_objects/thread.md
index be25899..d297989 100644
--- a/docs/reference/kernel_objects/thread.md
+++ b/docs/reference/kernel_objects/thread.md
@@ -12,7 +12,7 @@
The thread object is the construct that represents a time-shared CPU execution
context. Thread objects live associated to a particular
-[Process Object](process.md) which provides the memory and the handles to other
+[Process Object](process.md), which provides the memory and the handles to other
objects necessary for I/O and computation.
### Lifetime
diff --git a/docs/reference/syscalls/README.md b/docs/reference/syscalls/README.md
index d511c14..af7f8a1 100644
--- a/docs/reference/syscalls/README.md
+++ b/docs/reference/syscalls/README.md
@@ -233,8 +233,8 @@
## Syscall generation
Syscall support is generated from `//zircon/vdso`. The FIDL files in that
-directory are first run through `fidlc` which produces an intermediate format.
-That intermediate format is consumed by [kazoo](/zircon/tools/kazoo) which
+directory are first run through `fidlc`, which produces an intermediate format.
+That intermediate format is consumed by [kazoo](/zircon/tools/kazoo), which
produces output for both the kernel and userspace in a variety of languages.
This output includes C or C++ headers for both the kernel and userspace, syscall
entry points, other language bindings, and so on.
diff --git a/docs/reference/syscalls/channel_write.md b/docs/reference/syscalls/channel_write.md
index 32f2143..913c94f 100644
--- a/docs/reference/syscalls/channel_write.md
+++ b/docs/reference/syscalls/channel_write.md
@@ -39,15 +39,15 @@
It is invalid to include *handle* (the handle of the channel being written
to) in the *handles* array (the handles being sent in the message).
-The maximum number of handles which may be sent in a message is
+The maximum number of handles that may be sent in a message is
**ZX_CHANNEL_MAX_MSG_HANDLES**, which is 64.
-The maximum number of bytes which may be sent in a message is
+The maximum number of bytes that may be sent in a message is
**ZX_CHANNEL_MAX_MSG_BYTES**, which is 65536.
Messages are drained by [`zx_channel_read()`] or [`zx_channel_read_etc()`].
Failure to drain the messages in a timely fashion can cause excessive kernel
-memory to be used which might generate an exception. See
+memory to be used, which might generate an exception. See
[ipc limits](/docs/concepts/kernel/ipc_limits.md) for details.
### ZX_CHANNEL_WRITE_USE_IOVEC option
diff --git a/docs/reference/syscalls/channel_write_etc.md b/docs/reference/syscalls/channel_write_etc.md
index ec7a034..ebd6dc7 100644
--- a/docs/reference/syscalls/channel_write_etc.md
+++ b/docs/reference/syscalls/channel_write_etc.md
@@ -71,14 +71,14 @@
It is invalid to include *handle* (the handle of the channel being written to) in the
*handles* array (the handles being sent in the message).
-The maximum number of handles which may be sent in a message is **ZX_CHANNEL_MAX_MSG_HANDLES**,
+The maximum number of handles that may be sent in a message is **ZX_CHANNEL_MAX_MSG_HANDLES**,
which is 64.
-The maximum number of bytes which may be sent in a message is **ZX_CHANNEL_MAX_MSG_BYTES**,
+The maximum number of bytes that may be sent in a message is **ZX_CHANNEL_MAX_MSG_BYTES**,
which is 65536.
Messages are drained by [`zx_channel_read()`] or [`zx_channel_read_etc()`]. Failure to drain the
-messages in a timely fashion can cause excessive kernel memory to be used which might generate an
+messages in a timely fashion can cause excessive kernel memory to be used, which might generate an
exception. See [ipc limits](/docs/concepts/kernel/ipc_limits.md) for details.
### ZX_CHANNEL_WRITE_USE_IOVEC option
diff --git a/docs/reference/syscalls/clock_create.md b/docs/reference/syscalls/clock_create.md
index 30d8df7..e8270e2 100644
--- a/docs/reference/syscalls/clock_create.md
+++ b/docs/reference/syscalls/clock_create.md
@@ -33,14 +33,14 @@
The following options are defined for clock objects:
-+ **ZX_CLOCK_OPT_MONOTONIC** : When set, creates a clock object which is
++ **ZX_CLOCK_OPT_MONOTONIC** : When set, creates a clock object that is
guaranteed to never run backwards. Monotonic clocks must always move forward.
-+ **ZX_CLOCK_OPT_CONTINUOUS** : When set, creates a clock which is guaranteed to
++ **ZX_CLOCK_OPT_CONTINUOUS** : When set, creates a clock that is guaranteed to
never jump either forwards or backwards. Continuous clocks may only be
maintained using frequency adjustments and are, by definition, also monotonic.
Attempting to create a clock object with the **ZX_CLOCK_OPT_CONTINUOUS** option
specified, but without the **ZX_CLOCK_OPT_MONOTONIC** option specified is an
- error which will be signalled with **ZX_ERR_INVALID_ARGS**.
+ error, which will be signalled with **ZX_ERR_INVALID_ARGS**.
+ **ZX_CLOCK_OPT_AUTO_START** : When set, creates a clock that is started
automatically for the user. You don't need to call zx_clock_update() to start
the clock running. Initially, the clock will be a clone of clock monotonic,
diff --git a/docs/reference/syscalls/clock_get.md b/docs/reference/syscalls/clock_get.md
index 9b45a81a..1485479 100644
--- a/docs/reference/syscalls/clock_get.md
+++ b/docs/reference/syscalls/clock_get.md
@@ -10,7 +10,7 @@
`zx_clock_adjust` is currently **DEPRECATED**. Do not make use of it in any new
code. See the [ALTERNATIVES](#alternatives) section of this page for the
-updated way to fetch the values which used to be accessible via
+updated way to fetch the values that used to be accessible via
`zx_clock_get()`.
## SYNOPSIS
@@ -53,7 +53,7 @@
## ALTERNATIVES {#alternatives}
`zx_clock_get()` has been **deprecated**. Refer to the instructions below on how
-to gain access to the timelines which had been accessible via calls to
+to gain access to the timelines that had been accessible via calls to
`zx_clock_get()`.
1. [`ZX_CLOCK_MONOTONIC`](#alternative-zx-clock-monotonic)
@@ -64,7 +64,7 @@
`zx_clock_get(ZX_CLOCK_MONOTONIC, out_ptr)` has been replaced with calls to
[`zx_clock_get_monotonic()`](clock_get_monotonic.md). Unlike `zx_clock_get`,
-`zx_clock_get_monotonic` is almost always implemented in a way which does not
+`zx_clock_get_monotonic` is almost always implemented in a way that does not
need an actual syscall (which can provide a performance benefit) and it cannot
ever return an error (which can help to simplify code). For example:
@@ -82,10 +82,10 @@
### `ZX_CLOCK_UTC` {#alternative-zx-clock-utc}
-Supplying a clock which provides an accurate representation of the UTC timeline
-is no longer a feature which is provided directly by the kernel. Instead, it
+Supplying a clock that provides an accurate representation of the UTC timeline
+is no longer a feature provided directly by the kernel. Instead, it
has become the responsibility of the Component Manager to distribute a handle to
-a [kernel clock object](../kernel_objects/clock.md) to processes which
+a [kernel clock object](../kernel_objects/clock.md) to processes that
are permitted to access UTC. This clock handle (when available) is used by the
various runtimes to implement their version of access to UTC. In addition, some
runtimes may provide direct access to this clock handle allowing the user to get
@@ -155,7 +155,7 @@
### `ZX_CLOCK_THREAD` {#alternative-zx-clock-thread}
The `ZX_CLOCK_THREAD` clock was never really a clock at all. Instead it
-provided access to value which was a property of a thread object, specifically
+provided access to value that was a property of a thread object, specifically
the cumulative runtime of the calling thread.
Moving forward, this value can be accessed for any thread using
@@ -163,7 +163,7 @@
[`ZX_INFO_THREAD_STATS`](object_get_info.md#zx-info-thread-stats).
Users will need to have access to the handle thread they wish to query, and that
handle will need to have `ZX_RIGHT_INSPECT` rights set on it. This is generally
-the case for threads in a process which have been created by the user.
+the case for threads in a process created by the user.
Here is an example of how to query this value for the current thread running in
the C/C++ runtime. The specific API for obtaining access to the current
diff --git a/docs/reference/syscalls/clock_get_details.md b/docs/reference/syscalls/clock_get_details.md
index de84ae6..bc31fa3 100644
--- a/docs/reference/syscalls/clock_get_details.md
+++ b/docs/reference/syscalls/clock_get_details.md
@@ -57,7 +57,7 @@
## ERRORS
- **ZX_ERR_BAD_HANDLE** : *handle* is either an invalid handle, or a handle to
- an object type which is not **ZX_OBJ_TYPE_CLOCK**.
+ an object type that is not **ZX_OBJ_TYPE_CLOCK**.
- **ZX_ERR_ACCESS_DENIED** : *handle* lacks the **ZX_RIGHT_READ** right.
- **ZX_ERR_INVALID_ARGS** : The version of the details structure signaled by
`options` is invalid, or the pointer of the structure passed via `details` is bad.
diff --git a/docs/reference/syscalls/clock_read.md b/docs/reference/syscalls/clock_read.md
index 14ada7a..7fb1232 100644
--- a/docs/reference/syscalls/clock_read.md
+++ b/docs/reference/syscalls/clock_read.md
@@ -34,7 +34,7 @@
## ERRORS
- **ZX_ERR_BAD_HANDLE** : *handle* is either an invalid handle, or a handle to
- an object type which is not **ZX_OBJ_TYPE_CLOCK**.
+ an object type that is not **ZX_OBJ_TYPE_CLOCK**.
- **ZX_ERR_ACCESS_DENIED** : *handle* lacks the **ZX_RIGHT_READ** right.
## SEE ALSO
diff --git a/docs/reference/syscalls/clock_update.md b/docs/reference/syscalls/clock_update.md
index c995cf8..008899c 100644
--- a/docs/reference/syscalls/clock_update.md
+++ b/docs/reference/syscalls/clock_update.md
@@ -45,7 +45,7 @@
In order to update a clock, a user fills out the fields of a
`zx_clock_update_args_v1_t` structure that they wish to adjust, then passes the
-structure to the update call, setting the bits in `options` which indicate which
+structure to the update call, setting the bits in `options` that indicate which
of these fields are valid and should be set. Defined `options` bits are
+ **ZX_CLOCK_UPDATE_OPTION_VALUE_VALID**
@@ -110,7 +110,7 @@
## ERRORS
- **ZX_ERR_BAD_HANDLE** : *handle* is either an invalid handle, or a handle to
- an object type which is not **ZX_OBJ_TYPE_CLOCK**.
+ an object type that is not **ZX_OBJ_TYPE_CLOCK**.
- **ZX_ERR_ACCESS_DENIED** : *handle* lacks the **ZX_RIGHT_WRITE** right.
- **ZX_ERR_INVALID_ARGS** : The update request made is incompatible with the
properties of the clock. See the **DESCRIPTION** section for details of
diff --git a/docs/reference/syscalls/futex_requeue.md b/docs/reference/syscalls/futex_requeue.md
index 4f99e2c..d645d80 100644
--- a/docs/reference/syscalls/futex_requeue.md
+++ b/docs/reference/syscalls/futex_requeue.md
@@ -49,7 +49,7 @@
a futex, use the [`zx_futex_requeue_single_owner()`] variant instead.
[`zx_futex_requeue_single_owner()`] will attempt to wake exactly one thread from the
futex wait queue. If there is at least one thread to wake, the owner of the futex will be
-set to the thread which was woken. Otherwise, the futex
+set to the thread that was woken. Otherwise, the futex
will have no owner.
### Effects on the _requeue futex_ target
diff --git a/docs/reference/syscalls/futex_wake.md b/docs/reference/syscalls/futex_wake.md
index 36237c9..af2ce6e 100644
--- a/docs/reference/syscalls/futex_wake.md
+++ b/docs/reference/syscalls/futex_wake.md
@@ -31,7 +31,7 @@
a futex, use the [`zx_futex_wake_single_owner()`] variant instead.
[`zx_futex_wake_single_owner()`] will attempt to wake exactly one thread from the
futex wait queue. If there is at least one thread to wake, the owner of the
-futex will be set to the thread which was woken. Otherwise, the futex will have
+futex will be set to the thread that was woken. Otherwise, the futex will have
no owner.
See *Ownership and Priority Inheritance* in [futex](/docs/reference/kernel_objects/futex.md) for
diff --git a/docs/reference/syscalls/interrupt_ack.md b/docs/reference/syscalls/interrupt_ack.md
index a44760d..cfa7611 100644
--- a/docs/reference/syscalls/interrupt_ack.md
+++ b/docs/reference/syscalls/interrupt_ack.md
@@ -28,7 +28,7 @@
Virtual interrupts behave as edge interrupts.
-This syscall only operates on interrupts which are bound to a port. Interrupts
+This syscall only operates on interrupts bound to a port. Interrupts
being waited upon with [`zx_interrupt_wait()`] do not need to be re-armed with this
call -- it happens automatically when [`zx_interrupt_wait()`] is called.
diff --git a/docs/reference/syscalls/interrupt_bind.md b/docs/reference/syscalls/interrupt_bind.md
index 1b65309..219e166 100644
--- a/docs/reference/syscalls/interrupt_bind.md
+++ b/docs/reference/syscalls/interrupt_bind.md
@@ -24,7 +24,7 @@
`zx_interrupt_bind()` binds or unbinds an interrupt object to a port.
An interrupt object may only be bound to a single port and may only be bound once.
-The interrupt can only bind to a port which is created with **ZX_PORT_BIND_TO_INTERRUPT**
+The interrupt can only bind to a port created with **ZX_PORT_BIND_TO_INTERRUPT**
option.
When a bound interrupt object is triggered, a **ZX_PKT_TYPE_INTERRUPT** packet will
diff --git a/docs/reference/syscalls/interrupt_create.md b/docs/reference/syscalls/interrupt_create.md
index 7bfaab3..e631f38 100644
--- a/docs/reference/syscalls/interrupt_create.md
+++ b/docs/reference/syscalls/interrupt_create.md
@@ -21,7 +21,7 @@
## DESCRIPTION
-`zx_interrupt_create()` creates an interrupt object which represents a physical
+`zx_interrupt_create()` creates an interrupt object that represents a physical
or virtual interrupt.
If *options* is **ZX_INTERRUPT_VIRTUAL**, *src_obj* and *src_num* are ignored and
diff --git a/docs/reference/syscalls/interrupt_wait.md b/docs/reference/syscalls/interrupt_wait.md
index f946c6c..1161aef 100644
--- a/docs/reference/syscalls/interrupt_wait.md
+++ b/docs/reference/syscalls/interrupt_wait.md
@@ -18,7 +18,7 @@
## DESCRIPTION
-`zx_interrupt_wait()` is a blocking syscall which causes the caller to
+`zx_interrupt_wait()` is a blocking syscall that causes the caller to
wait until an interrupt is triggered. It can only be used on interrupt
objects that have not been bound to a port with [`zx_interrupt_bind()`]
diff --git a/docs/reference/syscalls/job_set_policy.md b/docs/reference/syscalls/job_set_policy.md
index bdf9856..30f8565 100644
--- a/docs/reference/syscalls/job_set_policy.md
+++ b/docs/reference/syscalls/job_set_policy.md
@@ -103,7 +103,7 @@
**ZX_POL_NEW_CHANNEL**, **ZX_POL_NEW_EVENT**, **ZX_POL_NEW_EVENTPAIR**,
**ZX_POL_NEW_PORT**, **ZX_POL_NEW_SOCKET**, **ZX_POL_NEW_FIFO**,
and any future **ZX_NEW** policy. This will include any new
- kernel objects which do not require a parent object for creation.
+ kernel objects that do not require a parent object for creation.
Where *policy* for **ZX_JOB_POL_BASIC_V1** or *action* for **ZX_JOB_POL_BASIC_V2**
is one of
diff --git a/docs/reference/syscalls/object_get_info.md b/docs/reference/syscalls/object_get_info.md
index b8eb15f..572a6e1 100644
--- a/docs/reference/syscalls/object_get_info.md
+++ b/docs/reference/syscalls/object_get_info.md
@@ -126,7 +126,7 @@
// The object type: channel, event, socket, etc.
zx_obj_type_t type;
- // The handle value which is only valid for the process which
+ // The handle value, which is only valid for the process that
// was passed to ZX_INFO_HANDLE_TABLE.
zx_handle_t handle_value;
@@ -688,7 +688,7 @@
Note: The same VMO may appear multiple times due to multiple mappings or
handles, or because a handle to the VMO has been removed and then readded
-concurrently with this call. VMOs can change as the target process runs which
+concurrently with this call. VMOs can change as the target process runs, which
may result in the same VMO having different values each time it appears. The
caller must resolve any duplicate values.
diff --git a/docs/reference/syscalls/object_wait_async.md b/docs/reference/syscalls/object_wait_async.md
index 6a70c12..27320b3 100644
--- a/docs/reference/syscalls/object_wait_async.md
+++ b/docs/reference/syscalls/object_wait_async.md
@@ -22,7 +22,7 @@
## DESCRIPTION
-`zx_object_wait_async()` is a non-blocking syscall which causes packets to be
+`zx_object_wait_async()` is a non-blocking syscall that causes packets to be
enqueued on *port* when the object specified by *handle* has one or more of the
specified [signals] asserted. Use [`zx_port_wait()`] to retrieve the packets.
diff --git a/docs/reference/syscalls/object_wait_many.md b/docs/reference/syscalls/object_wait_many.md
index 482c8d4..da92b77 100644
--- a/docs/reference/syscalls/object_wait_many.md
+++ b/docs/reference/syscalls/object_wait_many.md
@@ -20,7 +20,7 @@
## DESCRIPTION
-`zx_object_wait_many()` is a blocking syscall which causes the caller to wait
+`zx_object_wait_many()` is a blocking syscall that causes the caller to wait
until either the *deadline* passes or at least one object referred to in
*items* has a specified [signal][signals] asserted. If an object is already
asserting at least one of the specified signals, the wait ends immediately with
diff --git a/docs/reference/syscalls/object_wait_one.md b/docs/reference/syscalls/object_wait_one.md
index 70224ac..f74820d 100644
--- a/docs/reference/syscalls/object_wait_one.md
+++ b/docs/reference/syscalls/object_wait_one.md
@@ -21,7 +21,7 @@
## DESCRIPTION
-`zx_object_wait_one()` is a blocking syscall which causes the caller to wait
+`zx_object_wait_one()` is a blocking syscall that causes the caller to wait
until either the *deadline* passes or the object to which *handle* refers
asserts at least one [signal][signals] specified by the bitmask *signals*. If
the object is already asserting at least one of the specified *signals*, the
diff --git a/docs/reference/syscalls/pager_create_vmo.md b/docs/reference/syscalls/pager_create_vmo.md
index 2abac88..a7ba6f5 100644
--- a/docs/reference/syscalls/pager_create_vmo.md
+++ b/docs/reference/syscalls/pager_create_vmo.md
@@ -27,7 +27,7 @@
boundary, and *options* must be zero or **ZX_VMO_RESIZABLE**.
On success, the returned vmo has the same rights as a vmo created with [`zx_vmo_create()`], as well
-as having the same behavior with respect to **ZX_VMO_ZERO_CHILDREN**. Syscalls which operate on VMOs
+as having the same behavior with respect to **ZX_VMO_ZERO_CHILDREN**. Syscalls that operate on VMOs
require an explicit flag to allow blocking IPC to the userspace pager service; beyond this, whether
or not a VMO is owned by a pager does not affect the semantics of syscalls.
diff --git a/docs/reference/syscalls/pager_detach_vmo.md b/docs/reference/syscalls/pager_detach_vmo.md
index 0833159..34c75d9 100644
--- a/docs/reference/syscalls/pager_detach_vmo.md
+++ b/docs/reference/syscalls/pager_detach_vmo.md
@@ -19,11 +19,11 @@
## DESCRIPTION
Detaching *vmo* from *pager* causes the kernel to stop queuing page requests for the vmo. Subsequent
-accesses which would have generated page requests will instead fail.
+accesses that would have generated page requests will instead fail.
No new **ZX_PAGER_VMO_READ** requests will be generated after detaching, but some requests may
still be in flight. The pager service is free to ignore these requests, as the kernel will resume and
-fault the threads which generated these requests. The final request the pager service will
+fault the threads that generated these requests. The final request the pager service will
receive is a **ZX_PAGER_VMO_COMPLETE** request.
The kernel is free to evict clean pages from deregistered vmos.
diff --git a/docs/reference/syscalls/port_cancel.md b/docs/reference/syscalls/port_cancel.md
index 6240d44..f7d9f81 100644
--- a/docs/reference/syscalls/port_cancel.md
+++ b/docs/reference/syscalls/port_cancel.md
@@ -20,7 +20,7 @@
## DESCRIPTION
-`zx_port_cancel()` is a non-blocking syscall which cancels
+`zx_port_cancel()` is a non-blocking syscall that cancels
pending [`zx_object_wait_async()`] calls done with *source* and *key*.
When this call succeeds no new packets from the object pointed by
diff --git a/docs/reference/syscalls/port_queue.md b/docs/reference/syscalls/port_queue.md
index e7119d6..92d4ca9 100644
--- a/docs/reference/syscalls/port_queue.md
+++ b/docs/reference/syscalls/port_queue.md
@@ -22,7 +22,7 @@
`zx_port_queue()` queues a user *packet* to the port specified by *handle*.
User packets are drained by [`zx_port_wait()`]. Failure to drain packets in a
-timely fashion can cause excessive kernel memory to be used which might generate
+timely fashion can cause excessive kernel memory to be used, which might generate
an exception. See [ipc limits](/docs/concepts/kernel/ipc_limits.md) for details.
```
diff --git a/docs/reference/syscalls/port_wait.md b/docs/reference/syscalls/port_wait.md
index be45235..cf08b1c 100644
--- a/docs/reference/syscalls/port_wait.md
+++ b/docs/reference/syscalls/port_wait.md
@@ -21,7 +21,7 @@
## DESCRIPTION
-`zx_port_wait()` is a blocking syscall which causes the caller to wait until at least
+`zx_port_wait()` is a blocking syscall, which causes the caller to wait until at least
one packet is available.
Upon return, if successful *packet* will contain the earliest (in FIFO order)
@@ -35,7 +35,7 @@
unless a packet is already available for reading.
Unlike [`zx_object_wait_one()`] and [`zx_object_wait_many()`] only one
-waiting thread is released (per available packet) which makes ports
+waiting thread is released (per available packet), which makes ports
amenable to be serviced by thread pools.
There are two classes of packets: packets queued by userspace with [`zx_port_queue()`]
diff --git a/docs/reference/syscalls/process_start.md b/docs/reference/syscalls/process_start.md
index 0de2a0f..208d73c 100644
--- a/docs/reference/syscalls/process_start.md
+++ b/docs/reference/syscalls/process_start.md
@@ -33,7 +33,7 @@
before the thread is started. All other registers are zero upon start.
The first argument (*arg1*) is a handle, which will be transferred from
-the process of the caller to the process which is being started, and an
+the process of the caller to the process being started, and an
appropriate handle value will be placed in arg1 for the newly started
thread. If `zx_process_start()` returns an error, *arg1* is closed rather
than transferred to the process being started.
diff --git a/docs/reference/syscalls/task_create_exception_channel.md b/docs/reference/syscalls/task_create_exception_channel.md
index 4409a99..68f1d4d 100644
--- a/docs/reference/syscalls/task_create_exception_channel.md
+++ b/docs/reference/syscalls/task_create_exception_channel.md
@@ -20,7 +20,7 @@
## DESCRIPTION
-`zx_task_create_exception_channel()` creates a channel which will receive
+`zx_task_create_exception_channel()` creates a channel that will receive
exceptions from the thread, process, or job.
*handle* is the thread, process, or job handle to receive exceptions from.
diff --git a/docs/reference/syscalls/thread_read_state.md b/docs/reference/syscalls/thread_read_state.md
index e53bdb4..b93ae30 100644
--- a/docs/reference/syscalls/thread_read_state.md
+++ b/docs/reference/syscalls/thread_read_state.md
@@ -52,7 +52,7 @@
### ZX_THREAD_STATE_SINGLE_STEP
-The buffer must point to a `zx_thread_state_single_step_t` value which
+The buffer must point to a `zx_thread_state_single_step_t` value, which
may contain either 0 (normal running), or 1 (single stepping enabled).
## RIGHTS
diff --git a/docs/reference/syscalls/timer_create.md b/docs/reference/syscalls/timer_create.md
index 7ca13c3..ecd05c9 100644
--- a/docs/reference/syscalls/timer_create.md
+++ b/docs/reference/syscalls/timer_create.md
@@ -24,7 +24,7 @@
when a specified point in time has been reached. The only valid
*clock_id* is **ZX_CLOCK_MONOTONIC**.
-The *options* value specifies the coalescing behavior which
+The *options* value specifies the coalescing behavior, which
controls whether the system can fire the time earlier or later
depending on other pending timers.
diff --git a/docs/reference/syscalls/vmo_op_range.md b/docs/reference/syscalls/vmo_op_range.md
index 0924aee..da62b44 100644
--- a/docs/reference/syscalls/vmo_op_range.md
+++ b/docs/reference/syscalls/vmo_op_range.md
@@ -39,7 +39,7 @@
**ZX_VMO_OP_DECOMMIT** - Release a range of pages previously committed to the VMO from *offset*
to *offset*+*size*, which resets that range's bytes to 0. Requires the **ZX_RIGHT_WRITE** right.
-This is only supported for vmos created from [`zx_vmo_create()`] which do not have non-slice
+This is only supported for vmos created from [`zx_vmo_create()`], which do not have non-slice
children, and for slice children of such vmos. Provided range must be page aligned.
**ZX_VMO_OP_ZERO** - Resets the range of bytes in the VMO from *offset* to *offset*+*size* to
diff --git a/docs/reference/tracing/FIFO-packets.md b/docs/reference/tracing/FIFO-packets.md
index 80c54a7..21024a4 100644
--- a/docs/reference/tracing/FIFO-packets.md
+++ b/docs/reference/tracing/FIFO-packets.md
@@ -45,7 +45,7 @@
This packet is sent from trace providers to the trace manager in streaming
mode. Notifies the trace manager that a buffer is full and needs saving.
-The `data32` field contains the wrap count which is the number of times
+The `data32` field contains the wrap count, which is the number of times
writing has switched from one buffer to the next. The buffer that needs saving
is `(data32 & 1)`. The `data64` field contains the offset of the end of
data written to the durable buffer.
diff --git a/docs/reference/tracing/c_cpp_macros.md b/docs/reference/tracing/c_cpp_macros.md
index e250908..469392f 100644
--- a/docs/reference/tracing/c_cpp_macros.md
+++ b/docs/reference/tracing/c_cpp_macros.md
@@ -71,7 +71,7 @@
<tr>
<td><code>TA_CHAR_ARRAY</code></td>
<td><p><b>Required for C++</b></p>
- <p>A character array with a length which is copied rather than cached.</p>
+ <p>A character array with a length, which is copied rather than cached.</p>
<p>This macro takes two arguments. The first argument is a pointer to
the character array. The second argument is the length of the array.</p>
</td>
@@ -79,19 +79,19 @@
<tr>
<td><code>TA_STRING</code></td>
<td><p><b>Optional for C++</b></p>
- <p>A NULL terminated dynamic string which is copied rather than cached.</p>
+ <p>A NULL terminated dynamic string, which is copied rather than cached.</p>
</td>
<tr>
<tr>
<td><code>TA_STRING_LITERAL</code></td>
<td><p><b>Required for C++</b></p>
- <p>A NULL terminated dynamic string which is cached.</p>
+ <p>A NULL terminated dynamic string, which is cached.</p>
</td>
<tr>
<tr>
<td><code>TA_POINTER</code></td>
<td><p><b>Optional for C++</b></p>
- <p>A pointer value which records the memory address
+ <p>A pointer value that records the memory address
and not the target.</p>
</td>
<tr>
@@ -221,7 +221,7 @@
The arguments to this event are numeric samples are typically represented by
the visualizer as a stacked area chart. The id serves to distinguish multiple
- instances of counters which share the same category and name within the
+ instances of counters that share the same category and name within the
same process.
1 to 15 numeric arguments can be associated with the event, each of which is
@@ -242,9 +242,9 @@
## TRACE_DURATION {#TRACE_DURATION}
```
- Writes a duration event which ends when the current scope exits.
+ Writes a duration event that ends when the current scope exits.
- Durations describe work which is happening synchronously on one thread.
+ Durations describe work that is happening synchronously on one thread.
They can be nested to represent a control flow stack.
0 to 15 arguments can be associated with the event, each of which is used
@@ -268,7 +268,7 @@
Writes a duration begin event only.
This event must be matched by a duration end event with the same category and name.
- Durations describe work which is happening synchronously on one thread.
+ Durations describe work that is happening synchronously on one thread.
They can be nested to represent a control flow stack.
0 to 15 arguments can be associated with the event, each of which is used
@@ -290,7 +290,7 @@
```
Writes a duration end event only.
- Durations describe work which is happening synchronously on one thread.
+ Durations describe work that is happening synchronously on one thread.
They can be nested to represent a control flow stack.
0 to 15 arguments can be associated with the event, each of which is used
@@ -314,9 +314,9 @@
This event may be followed by async instant events and must be matched by
an async end event with the same category, name, and id.
- Asynchronous events describe work which is happening asynchronously and which
+ Asynchronous events describe work that is happening asynchronously and that
may span multiple threads. Asynchronous events do not nest. The id serves
- to correlate the progress of distinct asynchronous operations which share
+ to correlate the progress of distinct asynchronous operations that share
the same category and name within the same process.
0 to 15 arguments can be associated with the event, each of which is used
@@ -341,9 +341,9 @@
```
Writes an asynchronous instant event with the specified id.
- Asynchronous events describe work which is happening asynchronously and which
+ Asynchronous events describe work that is happening asynchronously and that
may span multiple threads. Asynchronous events do not nest. The id serves
- to correlate the progress of distinct asynchronous operations which share
+ to correlate the progress of distinct asynchronous operations that share
the same category and name within the same process.
0 to 15 arguments can be associated with the event, each of which is used
@@ -368,9 +368,9 @@
```
Writes an asynchronous end event with the specified id.
- Asynchronous events describe work which is happening asynchronously and which
+ Asynchronous events describe work that is happening asynchronously and that
may span multiple threads. Asynchronous events do not nest. The id serves
- to correlate the progress of distinct asynchronous operations which share
+ to correlate the progress of distinct asynchronous operations that share
the same category and name within the same process.
0 to 15 arguments can be associated with the event, each of which is used
@@ -399,12 +399,12 @@
Flow events describe control flow handoffs between threads or across processes.
They are typically represented as arrows in a visualizer. Flow arrows are
- from the end of the duration event which encloses the beginning of the flow
- to the beginning of the duration event which encloses the next step or the
- end of the flow. The id serves to correlate flows which share the same
+ from the end of the duration event that encloses the beginning of the flow
+ to the beginning of the duration event that encloses the next step or the
+ end of the flow. The id serves to correlate flows that share the same
category and name across processes.
- This event must be enclosed in a duration event which represents where
+ This event must be enclosed in a duration event that represents where
the flow handoff occurs.
0 to 15 arguments can be associated with the event, each of which is used
@@ -431,12 +431,12 @@
Flow events describe control flow handoffs between threads or across processes.
They are typically represented as arrows in a visualizer. Flow arrows are
- from the end of the duration event which encloses the beginning of the flow
- to the beginning of the duration event which encloses the next step or the
- end of the flow. The id serves to correlate flows which share the same
+ from the end of the duration event that encloses the beginning of the flow
+ to the beginning of the duration event that encloses the next step or the
+ end of the flow. The id serves to correlate flows that share the same
category and name across processes.
- This event must be enclosed in a duration event which represents where
+ This event must be enclosed in a duration event that represents where
the flow handoff occurs.
0 to 15 arguments can be associated with the event, each of which is used
@@ -463,12 +463,12 @@
Flow events describe control flow handoffs between threads or across processes.
They are typically represented as arrows in a visualizer. Flow arrows are
- from the end of the duration event which encloses the beginning of the flow
- to the beginning of the duration event which encloses the next step or the
- end of the flow. The id serves to correlate flows which share the same
+ from the end of the duration event that encloses the beginning of the flow
+ to the beginning of the duration event that encloses the next step or the
+ end of the flow. The id serves to correlate flows that share the same
category and name across processes.
- This event must be enclosed in a duration event which represents where
+ This event must be enclosed in a duration event that represents where
the flow handoff occurs.
0 to 15 arguments can be associated with the event, each of which is used
@@ -495,8 +495,8 @@
Here metadata includes timestamp, thread and process information, and arguments,
which is what most event records contain.
- Blobs which exceed |TRACE_ENCODED_RECORD_MAX_TOTAL_LENGTH| will be silently
- ignored, as will blobs which cannot fit within the remaining space in the
+ Blobs that exceed |TRACE_ENCODED_RECORD_MAX_TOTAL_LENGTH| will be silently
+ ignored, as will blobs that cannot fit within the remaining space in the
trace buffer.
|category_literal| and |name_literal| must be null-terminated static string constants.
@@ -512,8 +512,8 @@
additional metadata. This means timestamp, thread and process information,
and arguments are not included with the record.
- Blobs which exceed |TRACE_ENCODED_RECORD_MAX_TOTAL_LENGTH| will be silently
- ignored, as will blobs which cannot fit within the remaining space in the
+ Blobs that exceed |TRACE_ENCODED_RECORD_MAX_TOTAL_LENGTH| will be silently
+ ignored, as will blobs that cannot fit within the remaining space in the
trace buffer.
|category_literal| and |name_literal| must be null-terminated static string constants.
diff --git a/docs/reference/tracing/trace-format.md b/docs/reference/tracing/trace-format.md
index df8a5ff..5616ff3 100644
--- a/docs/reference/tracing/trace-format.md
+++ b/docs/reference/tracing/trace-format.md
@@ -22,7 +22,7 @@
record.
As the trace progresses, the trace manager aggregates records from all
-trace providers which are participating in trace collection and concatenates
+trace providers participating in trace collection, and concatenates
them together with some special metadata records to form a trace archive.
Once the trace completes, tools such as the `trace` command-line program
@@ -62,16 +62,16 @@
Each record is constructed as a sequence of atoms.
-Each atom is written with 8 byte alignment and has a size which is also a
+Each atom is written with 8 byte alignment and has a size that is also a
multiple of 8 bytes so as to preserve alignment.
There are two kinds of atoms:
-- **Word**: A 64-bit value which may be further subdivided into bit fields.
+- **Word**: A 64-bit value that may be further subdivided into bit fields.
Words are stored in machine word order (little-endian on all currently
supported architectures).
- **Stream**: A sequence of bytes padded with zeros to the next 8 byte
- boundary. Streams are stored in byte order. Streams which are an exact
+ boundary. Streams are stored in byte order. Streams that are an exact
multiple of 8 bytes long are not padded (there is no zero terminator).
**Fields** are subdivisions of 64-bit **Words**, denoted
@@ -90,12 +90,12 @@
A trace record is a binary encoded piece of trace information consisting of
a sequence of [atoms](#atoms).
-All records include a header word which contains the following basic
+All records include a header word that contains the following basic
information:
-- **Record type**: A 4-bit field which identifies the type of the record
+- **Record type**: A 4-bit field that identifies the type of the record
and the information it contains. See [Record Types](#record-types).
-- **Record size**: Typically, a 12-bit field which indicates the number of words
+- **Record size**: Typically, a 12-bit field that indicates the number of words
(multiples of 8 byte units) within the record _including the record
header itself_. The maximum possible size of a record is 4095 words
(32760 bytes). Very simple records may be just 1 word (8 bytes) long.
@@ -109,10 +109,10 @@
A trace archive is a sequence of trace records, concatenated end to end,
which stores information collected by trace providers while a trace is
-running together with metadata records which identify and delimit sections
+running together with metadata records that identify and delimit sections
of the trace produced by each trace provider.
-Trace archives are intended to be read sequentially since records which
+Trace archives are intended to be read sequentially since records that
appear earlier in the trace may influence the interpretation of records
which appear later in the trace. The trace system provides tools for
extracting information from trace archives and converting it into other
@@ -182,7 +182,7 @@
be associated with the referent's annotations.
This makes it easy to associate human-readable labels and other information
-with objects which appear later in the trace.
+with objects that appear later in the trace.
### Kernel object information {#kernel-object-information}
@@ -195,7 +195,7 @@
be associated with the referent's annotations.
This makes it easy to associate human-readable labels and other information
-with objects which appear later in the trace.
+with objects that appear later in the trace.
In particular, this is how the tracing system associates names with process
and thread koids.
@@ -249,7 +249,7 @@
### Record header {#record-header}
-All records include this header which specifies the record's type and size
+All records include this header that specifies the record's type and size
together with 48 bits of data whose usage varies by record type.
##### Format
@@ -278,7 +278,7 @@
### Metadata record (record type = 0) {#metadata-record}
-Provides metadata about trace data which follows.
+Provides metadata about trace data that follows.
This record type is reserved for use by the _trace manager_ when generating
trace archives. It must not be emitted by trace providers themselves.
@@ -301,10 +301,10 @@
#### Provider info metadata (metadata type = 1) {#provider-info-metadata}
-This metadata identifies a trace provider which has contributed information to
+This metadata identifies a trace provider that has contributed information to
the trace.
-All data which follows until the next **provider section metadata** or
+All data that follows until the next **provider section metadata** or
**provider info metadata** is encountered must have been collected from the
same provider.
@@ -327,10 +327,10 @@
#### Provider section metadata (metadata type = 2) {#provider-section-metadata}
-This metadata delimits sections of the trace which have been obtained from
+This metadata delimits sections of the trace that have been obtained from
different providers.
-All data which follows until the next **provider section metadata** or
+All data that follows until the next **provider section metadata** or
**provider info metadata** is encountered is assumed to have been collected
from the same provider.
@@ -425,7 +425,7 @@
### Initialization record (record type = 1) {#initialization-record}
-Provides parameters needed to interpret the records which follow. In absence
+Provides parameters needed to interpret the records that follow. In absence
of this record, the reader may assume that 1 tick is 1 nanosecond.
##### Format
@@ -446,12 +446,12 @@
Registers a string in the string table, assigning it a string index in the
range `0x0001` to `0x7fff`. The registration replaces any prior registration
-for the given string index when interpreting the records which follow.
+for the given string index when interpreting the records that follow.
-String records which attempt to set a value for string index `0x0000` must be
+String records that attempt to set a value for string index `0x0000` must be
ignored since this value is reserved to represent the empty string.
-String records which contain empty strings must be tolerated but they're
+String records that contain empty strings must be tolerated but they're
pointless since the empty string can simply be encoded as zero in a string ref.
##### Format
@@ -480,7 +480,7 @@
which follow.
Thread index `0x00` is reserved to denote the use of an inline thread id in
-a thread ref. Thread records which attempt to set a value for this value
+a thread ref. Thread records that attempt to set a value for this value
must be ignored.
##### Format
@@ -623,7 +623,7 @@
#### Async begin event (event type = 5) {#async-begin-event}
-Marks the beginning of an operation which may span threads. Must be matched
+Marks the beginning of an operation that may span threads. Must be matched
by an **async end event** using the same async correlation id.
##### Format
@@ -636,7 +636,7 @@
#### Async instant Event (event type = 6) {#async-instant-event}
-Marks a moment within an operation which may span threads. Must appear
+Marks a moment within an operation that may span threads. Must appear
between **async begin event** and **async end event** using the same async
correlation id.
@@ -650,7 +650,7 @@
#### Async end event (event type = 7) {#async-end-event}
-Marks the end of an operation which may span threads.
+Marks the end of an operation that may span threads.
##### Format
@@ -662,8 +662,8 @@
#### Flow begin event (event type = 8) {#flow-begin-event}
-Marks the beginning of an operation which results in a sequence of actions
-which may span multiple threads or abstraction layers. Must be matched by a
+Marks the beginning of an operation, which results in a sequence of actions
+that may span multiple threads or abstraction layers. Must be matched by a
**flow end event** using the same flow correlation id. This can be envisioned
as an arrow between duration events.
@@ -839,12 +839,12 @@
Note: This information may not always be available.
- `"process"`: for `ZX_OBJ_TYPE_THREAD` objects, specifies the koid of the
- process which contains the thread
+ process that contains the thread
### Context switch record (record type = 8) {#context-switch-record}
Describes a context switch during which a CPU handed off control from an
-outgoing thread to an incoming thread which resumes execution.
+outgoing thread to an incoming thread that resumes execution.
The record specifies the new state of the outgoing thread following the
context switch. By definition, the new state of the incoming thread is
@@ -1083,7 +1083,7 @@
### Argument header {#argument-header}
-All arguments include this header which specifies the argument's type,
+All arguments include this header, which specifies the argument's type,
name, and size together with 32 bits of data whose usage varies by
argument type.
@@ -1104,7 +1104,7 @@
### Null argument (argument type = 0) {#null-argument}
-Represents an argument which appears in name only without a value.
+Represents an argument that appears in name only, without a value.
##### Format
