doc: s/Incus's/Incus'/g

Signed-off-by: Stéphane Graber <stgraber@stgraber.org>

doc/README.md

@@ -10,7 +10,7 @@ GitHub provides a basic rendering of the documentation as well, but important fe
 
 ### Documentation framework
 
-Incus's documentation is built with [Sphinx](https://www.sphinx-doc.org/en/master/index.html).
+Incus' documentation is built with [Sphinx](https://www.sphinx-doc.org/en/master/index.html).
 
 It is written in [Markdown](https://commonmark.org/) with [MyST](https://myst-parser.readthedocs.io/) extensions.
 For syntax help and guidelines, see the [documentation cheat sheet](https://linuxcontainers.org/incus/docs/main/doc-cheat-sheet/) ([source](https://raw.githubusercontent.com/lxc/incus/main/doc/doc-cheat-sheet.md)).

doc/container-environment.md

@@ -86,7 +86,7 @@ On older kernels, a virtual version of `/sys/fs/cgroup` might also be set up by
 Incus spawns whatever is located at `/sbin/init` as the initial process of the container (PID 1).
 This binary should act as a proper init system, including handling re-parented processes.
 
-Incus's communication with PID1 in the container is limited to two signals:
+Incus' communication with PID1 in the container is limited to two signals:
 
 - `SIGINT` to trigger a reboot of the container
 - `SIGPWR` (or alternatively `SIGRTMIN`+3) to trigger a clean shutdown of the container

doc/explanation/clustering.md

@@ -174,12 +174,12 @@ For example:
 
 ```python
 def instance_placement(request, candidate_members):
-    # Example of logging info, this will appear in Incus's log.
+    # Example of logging info, this will appear in Incus' log.
     log_info("instance placement started: ", request)
 
     # Example of applying logic based on the instance request.
     if request.name == "foo":
-        # Example of logging an error, this will appear in Incus's log.
+        # Example of logging an error, this will appear in Incus' log.
         log_error("Invalid name supplied: ", request.name)
 
         fail("Invalid name") # Exit with an error to reject instance placement.
@@ -200,9 +200,9 @@ To see the current scriptlet applied to Incus, use the `incus config get instanc
 
 The following functions are available to the scriptlet (in addition to those provided by Starlark):
 
-- `log_info(*messages)`: Add a log entry to Incus's log at `info` level. `messages` is one or more message arguments.
-- `log_warn(*messages)`: Add a log entry to Incus's log at `warn` level. `messages` is one or more message arguments.
-- `log_error(*messages)`: Add a log entry to Incus's log at `error` level. `messages` is one or more message arguments.
+- `log_info(*messages)`: Add a log entry to Incus' log at `info` level. `messages` is one or more message arguments.
+- `log_warn(*messages)`: Add a log entry to Incus' log at `warn` level. `messages` is one or more message arguments.
+- `log_error(*messages)`: Add a log entry to Incus' log at `error` level. `messages` is one or more message arguments.
 - `set_cluster_member_target(member_name)`: Set the cluster member where the instance should be created. `member_name` is the name of the cluster member the instance should be created on. If this function is not called, then Incus will use its built-in instance placement logic.
 - `get_cluster_member_state(member_name)`: Get the cluster member's state. Returns an object with the cluster member's state in the form of [`api.ClusterMemberState`](https://pkg.go.dev/github.com/lxc/incus/shared/api#ClusterMemberState). `member_name` is the name of the cluster member to get the state for.
 - `get_cluster_member_resources(member_name)`: Get information about resources on the cluster member. Returns an object with the resource information in the form of [`api.Resources`](https://pkg.go.dev/github.com/lxc/incus/shared/api#Resources). `member_name` is the name of the cluster member to get the resource information for.

doc/howto/images_manage.md

@@ -60,7 +60,7 @@ To set a specific image property that is located under the `properties` key, ent
 
 ```{note}
 These properties can be used to convey information about the image.
-They do not configure Incus's behavior in any way.
+They do not configure Incus' behavior in any way.
 ```
 
 To edit the full image properties, including the top-level properties, enter the following command:

doc/howto/network_bridge_firewalld.md

@@ -22,7 +22,7 @@ Therefore, rules in one namespace can still affect rules in another namespace, a
 If your system supports and uses `nftables`, Incus detects this and switches to `nftables` mode.
 In this mode, Incus adds its rules into the `nftables`, using its own `nftables` namespace.
 
-## Use Incus's firewall
+## Use Incus' firewall
 
 By default, managed Incus bridges add firewall rules to ensure full functionality.
 If you do not run another firewall on your system, you can let Incus manage its firewall rules.
@@ -32,12 +32,12 @@ To enable or disable this behavior, use the `ipv4.firewall` or `ipv6.firewall` {
 ## Use another firewall
 
 Firewall rules added by other applications might interfere with the firewall rules that Incus adds.
-Therefore, if you use another firewall, you should disable Incus's firewall rules.
+Therefore, if you use another firewall, you should disable Incus' firewall rules.
 You must also configure your firewall to allow network traffic between the instances and the Incus bridge, so that the Incus instances can access the DHCP and DNS server that Incus runs on the host.
 
-See the following sections for instructions on how to disable Incus's firewall rules and how to properly configure `firewalld` and UFW, respectively.
+See the following sections for instructions on how to disable Incus' firewall rules and how to properly configure `firewalld` and UFW, respectively.
 
-### Disable Incus's firewall rules
+### Disable Incus' firewall rules
 
 Run the following commands to prevent Incus from setting firewall rules for a specific network bridge (for example, `incusbr0`):
 

doc/installing.md

@@ -144,7 +144,7 @@ Then proceed to the instructions below to actually build and install Incus.
 ### From source: Build a release
 
 The Incus release tarballs bundle a complete dependency tree as well as a
-local copy of `libraft` and `libcowsql` for Incus's database setup.
+local copy of `libraft` and `libcowsql` for Incus' database setup.
 
 ```bash
 tar zxvf incus-0.1.tar.gz

doc/reference/instance_options.md

@@ -257,7 +257,7 @@ For VM instances, Incus configures QEMU through a configuration file that is pas
 This configuration file is generated for each instance before boot.
 It can be found at `/var/log/incus/<instance_name>/qemu.conf`.
 
-The default configuration works fine for Incus's most common use case: modern UEFI guests with VirtIO devices.
+The default configuration works fine for Incus' most common use case: modern UEFI guests with VirtIO devices.
 In some situations, however, you might need to override the generated configuration.
 For example:
 

doc/requirements.md

@@ -30,7 +30,7 @@ As well as any other kernel feature required by the LXC version in use.
 
 Incus requires LXC 4.0.0 or higher with the following build options:
 
-* `apparmor` (if using Incus's AppArmor support)
+* `apparmor` (if using Incus' AppArmor support)
 * `seccomp`
 
 To run recent version of various distributions, including Ubuntu, LXCFS

doc/syscall-interception.md

@@ -51,7 +51,7 @@ Those can be attached to a variety of kernel subsystems.
 In general, loading of eBPF programs that are not trusted can be problematic as it
 can facilitate timing based attacks.
 
-Incus's eBPF support is currently restricted to programs managing devices
+Incus' eBPF support is currently restricted to programs managing devices
 cgroup entries. To enable it, you need to set both
 `security.syscalls.intercept.bpf` and
 `security.syscalls.intercept.bpf.devices` to true.