From 7dec40906433f08bbc4ee722d2032d1e99f4f89e Mon Sep 17 00:00:00 2001 From: Philip Molloy Date: Fri, 25 Oct 2024 12:14:59 +0200 Subject: [PATCH] cpu: Remove spaces after list markers Signed-off-by: Philip Molloy --- src/utilities/cpu.md | 68 ++++++++++++++++++++++---------------------- 1 file changed, 34 insertions(+), 34 deletions(-) diff --git a/src/utilities/cpu.md b/src/utilities/cpu.md index 35a55ca..6722cd0 100644 --- a/src/utilities/cpu.md +++ b/src/utilities/cpu.md @@ -194,29 +194,29 @@ but rather from the client to the server. The `cpu` client is a file server; the `cpu` server connects the kernel on the server machine to the file server in the client, as shown below. Things to note: -1. `Cpud`, on the remote or server machine, sets up a “private name space - mount” of `/tmp` for the program. “Private name space mount” just means that - only that program, and its children, can see what is in its private `/tmp`. - Other, external programs continue to use `/tmp`, but they are _different_ - instantiations of `/tmp`. -2. The private name space mount of `/tmp` is on a filesystem in RAM. The data - stored in `/tmp` is not visible to other processes, and not persistent. -3. `cpud` creates a directory, `cpu`, in the private `/tmp`; and mounts the - server on it. This mount point is also invisible outside the process and its - children. -4. To make sure that names like `/bin/bash`, and `/usr/lib/libc.so` work, - `cpud` sets up _bind mounts_ from, e.g., `/tmp/cpu/bin` to `/bin`. These are - also private mounts, and do not affect any program outside the one `cpud` - starts. Anytime the program and its children access files in `/bin`, `/lib`, - `/usr`, `/home/$USER`, and so on, they are accessing files from the client - machine via the built-in client file server. -5. The client `cpu` program passes the full environment from the client machine - to `cpud`. When the client program requests that, e.g., `bash` be run, the - `cpud` uses the PATH environment variable to locate `bash`. Because of the - private name space mounts and binds, `bash` will be found in `/bin/bash`, - and its libraries will be found in their usual place. This is an essential - property of `cpu`, that the names used on the user’s machine work the same - way on the remote machine. An overview of the process is shown below. +1. `Cpud`, on the remote or server machine, sets up a “private name space + mount” of `/tmp` for the program. “Private name space mount” just means that + only that program, and its children, can see what is in its private `/tmp`. + Other, external programs continue to use `/tmp`, but they are _different_ + instantiations of `/tmp`. +2. The private name space mount of `/tmp` is on a filesystem in RAM. The data + stored in `/tmp` is not visible to other processes, and not persistent. +3. `cpud` creates a directory, `cpu`, in the private `/tmp`; and mounts the + server on it. This mount point is also invisible outside the process and its + children. +4. To make sure that names like `/bin/bash`, and `/usr/lib/libc.so` work, + `cpud` sets up _bind mounts_ from, e.g., `/tmp/cpu/bin` to `/bin`. These are + also private mounts, and do not affect any program outside the one `cpud` + starts. Anytime the program and its children access files in `/bin`, `/lib`, + `/usr`, `/home/$USER`, and so on, they are accessing files from the client + machine via the built-in client file server. +5. The client `cpu` program passes the full environment from the client machine + to `cpud`. When the client program requests that, e.g., `bash` be run, the + `cpud` uses the PATH environment variable to locate `bash`. Because of the + private name space mounts and binds, `bash` will be found in `/bin/bash`, + and its libraries will be found in their usual place. This is an essential + property of `cpu`, that the names used on the user’s machine work the same + way on the remote machine. An overview of the process is shown below. @@ -349,14 +349,14 @@ years or so. The binaries include: -* A kernel (`cpukernel`) with a built-in initramfs containing `cpud`, as well - as a public key. Also included, should you want to build your own, is the - config file (`cpu.config`). -* A binary client program, `cpu`, as well as the private key to use. You can - place this key in `~/.ssh` or specify it via the `-key` option to `cpu`. -* A script to run the USB stick via `qemu` (`TESTQEMU`); and a script to run a - `cpu` command (`EXAMPLE`). -* The `extlinux.conf` used for the USB stick. +* A kernel (`cpukernel`) with a built-in initramfs containing `cpud`, as well + as a public key. Also included, should you want to build your own, is the + config file (`cpu.config`). +* A binary client program, `cpu`, as well as the private key to use. You can + place this key in `~/.ssh` or specify it via the `-key` option to `cpu`. +* A script to run the USB stick via `qemu` (`TESTQEMU`); and a script to run a + `cpu` command (`EXAMPLE`). +* The `extlinux.conf` used for the USB stick. `usbstick.xz` is a compressed USB stick image that is bootable. It will uncompress to about 7GB. You can use the `TESTQEMU` script to try it out, or use @@ -368,9 +368,9 @@ as part of the demo. The `cpukernel` was built using the `github.com:linuxboot/mainboards` repo. If you clone this repo, the following commands will rebuild the kernel: -* `cd mainboards/intel/generic` -* `make fetch` -* `make cpukernel` +* `cd mainboards/intel/generic` +* `make fetch` +* `make cpukernel` #### How to use the cpu binaries