Various improvements and fixes

1 files changed, 31 insertions, 10 deletions

diff --git a/doc/manual.cli b/doc/manual.cli
index 20e0846..abccb8b 100644
--- a/doc/manual.cli
+++ b/doc/manual.cli
@@ -34,9 +34,9 @@ mode} and receive \i{build tasks} from their respective agents.
 \h1#arch|Architecture|
 
 Build OS root filesystem (\c{rootfs}) resides entirely in RAM with all changes
-(such as installation of the \c{build2} toolchain} discarded on the next
+(such as installation of the \c{build2} toolchain) discarded on the next
 reboot. A small amount of persistent (but not precious) state is stored in
-\c{/state} (see \l{#config-storage-state State}). A minimum of 4G of RAM
+\c{/state} (see \l{#config-storage-state State}). A minimum of 4GB of RAM
 is required for Build OS itself (that is, excluding any virtual machines
 and containers).
 
@@ -180,13 +180,13 @@ sudo kvm \
 
 \h#config-cpu-ram|CPU and RAM|
 
-A Build OS instances divides available CPUs and RAM (minus 4G) into \i{slices}
-that are then \i{committed} to each toolchain. If you don't expect your
-toolchains to utilize these resources at the same time, then it may make
-sense to overcommit them to improve utilization. The respective overcommit
-values can be specified as ratios with the \c{buildos.cpu_overcommit}
-and \c{buildos.ram_overcommit} kernel command line parameters. For example,
-given the following CPU overcommit:
+A Build OS instances divides available CPUs and RAM (minus reserved, see
+below) into \i{slices} that are then \i{committed} to each instance of each
+toolchain. If you don't expect your builds to utilize these resources at the
+same time, then it may make sense to overcommit them to improve utilization.
+The respective overcommit values can be specified as ratios with the
+\c{buildos.cpu_overcommit} and \c{buildos.ram_overcommit} kernel command
+line parameters. For example, given the following CPU overcommit:
 
 \
 buildos.cpu_overcommit=3/2
@@ -195,6 +195,11 @@ buildos.cpu_overcommit=3/2
 A Build OS machine with 8 CPUs (hardware threads) and three toolchains will
 assign 4 CPUs (\c{8 * 3/2 / 3}) to each slice.
 
+It is also possible to reserve a number of CPUs and an amount of RAM to
+Build OS with the \c{buildos.cpu_reserved} and \c{buildos.ram_reserved}
+(in GB) kernel command line parameters. If unspecified, 4GB of RAM is
+reserved by default.
+
 
 \h#config-storage|Storage|
 
@@ -342,6 +347,19 @@ for example, \c{buildos.toolchain_url.<name>} (values without the toolchain
 name use the toolchain name \c{default}). The toolchain name may not contain
 \c{-}.
 
+Each toolchain may also execute multiple \c{bbot} agent instances. The number
+of instances is specified with the \c{buildos.instances[.<name>]} parameter.
+
+All \c{bbot} agent instances of a toolchain are executed with the same nice
+value which can be specified with the \c{buildos.nice[.<name>]} parameter. It
+should be between -20 (highest priority) and 19 (lowest priority) with 0
+being the default. See \cb{sched(7)} for details.
+
+The bridge interface to be used for machine networking can be specified with
+the \c{buildos.bridge[.<name>]} parameter. Valid values are \c{br0} (public
+bridge to the physical interface) and \c{br1} (private/NAT'ed bridge to
+\c{br0}). If unspecified, \c{br1} is used by default.
+
 In the checksums file blank lines and lines that start with \c{#} are ignored.
 If the first line is the special \c{disabled} value, then this toolchain is
 ignored. Otherwise, each line in the checksums file is the output of the
@@ -564,7 +582,10 @@ If the machine has been suspended, it can be resumed using the following
 command:
 
 \
-echo cont | ssh build@build socat - UNIX-CONNECT:/tmp/<toolchain>-monitor
+echo cont | ssh build@build socat - UNIX-CONNECT:/tmp/monitor-<toolchain>-<instance>
 \
 
+Other useful QEMU monitor commands are \c{system_powerdown} and
+\c{system_reset}.
+
 "