remove trailing spaces

Signed-off-by: Philip Molloy <philip@philipmolloy.com>

README.md

@@ -1,12 +1,12 @@
 # The LinuxBoot Book
 
 LinuxBoot is a project that aims to replace specific firmware functionality with
-a Linux kernel and runtime. Over the years this project has grown to include 
-various initiatives with the overarching goal of moving from obscure, complex 
-firmware to simpler, open source firmware. 
+a Linux kernel and runtime. Over the years this project has grown to include
+various initiatives with the overarching goal of moving from obscure, complex
+firmware to simpler, open source firmware.
 
-This is the official site of documentation for the LinuxBoot project. The book 
-provides guidance on how to get started, and gives overviews and 
+This is the official site of documentation for the LinuxBoot project. The book
+provides guidance on how to get started, and gives overviews and
 background on the different aspects of LinuxBoot.
 
 ## Table of Contents

UEFI_Tool_Kit/README.md

@@ -46,9 +46,9 @@ our first step on a new board.
 Get the tool:
 
     $ go get -u github.com/linuxboot/fiano/cmds/utk
-    
+
  Replace the shell:
- 
+
  	$ utk ROM.bin replace_pe32 Shell bzImage save NEWROM.bin
 
 After that, you can flash NEWROM.bin and test. If anything goes wrong, such as not enough space, you will need to refer to the more detailed instructions below.

case_studies/Google_study/README.md

@@ -4,7 +4,7 @@ Google runs workloads across a number of clusters each with up to tens of
 thousands of machines. Firmware runs on these machines when they first start
 up. Google is pushing the state-of-the-art in many places including firmware.
 The discussion here about Google's implementation of LinuxBoot is limited to
-replacing specific UEFI [firmware](https://github.com/linuxboot/book/blob/master/intro/glossary/README.md) 
+replacing specific UEFI [firmware](https://github.com/linuxboot/book/blob/master/intro/glossary/README.md)
 functionality with a Linux kernel and runtime. Over the years this project
 has grown to include various initiatives with the overarching goal of moving
 from obscure, complex firmware to simpler, open source firmware.
@@ -23,7 +23,7 @@ including:
 -  Andrew Sun
 
 Ryan O'Leary is one of the Open Compute Platform Foundation
-[Open System Firmware project](https://www.opencompute.org/projects/open-system-firmware) 
+[Open System Firmware project](https://www.opencompute.org/projects/open-system-firmware)
 volunteer leads and Ron Minnich is the Open Compute Platform Foundation
 Incubation Committee Representative.
 

case_studies/TiogaPass/README.md

@@ -51,16 +51,16 @@ wget -O TiogaPass.patch https://github.com/johnnylinwiwynn/linuxboot/commit/28ae
 git am TiogaPass.patch
 ```
 * Build the kernel bzImage (has embeded initramfs) for linuxboot, please reference
-  [Building u-root](https://github.com/linuxboot/book/tree/master/coreboot.u-root.systemboot#building-u-root) and 
+  [Building u-root](https://github.com/linuxboot/book/tree/master/coreboot.u-root.systemboot#building-u-root) and
   [Building a suitable Linux kernel](https://github.com/linuxboot/book/tree/master/coreboot.u-root.systemboot#building-a-suitable-linux-kernel)
   for how to build the bzImage. You can always customize your Linux kernel configuration to suit your needs, please reference Wiwynn's kernel configuration file as a sample [linux_config](linux_config).
-* Place the tioga.rom into linuxboot/boards/tioga which is provided from Wiwynn after ordering, and also put your bzImage 
+* Place the tioga.rom into linuxboot/boards/tioga which is provided from Wiwynn after ordering, and also put your bzImage
 to the root folder of linuxboot, and then make
 ```
   cp path/to/tioga.rom linuxboot/boards/tioga
   cp path/to/bzImage linuxboot
   cd linuxboot
-  BOARD=tioga make 
+  BOARD=tioga make
 ```
 * You should see the built image at build/tioga/linuxboot.rom.
 

coreboot.u-root.systemboot/README.md

@@ -10,7 +10,7 @@ The examples will focus on `x86_64`, and the coreboot builds will cover virtual
 Run these commands in a directory you create or in /tmp; do so because it creates some files and directories:
 
 	$ go get github.com/linuxboot/corebootnerf
-	$ go run github.com/linuxboot/corebootnerf --fetch 
+	$ go run github.com/linuxboot/corebootnerf --fetch
 	... lots and lots of output!
 
 This produces a coreboot image in coreboot-4.9/build/coreboot.rom

cpu/README.md

@@ -163,8 +163,8 @@ mount.
 
 ```
     rminnich@xcpu:~/gopath/src/github.com/u-root/u-root$ cpu apu2
-    root@(none):/# 
-    root@(none):/# ls ~ 
+    root@(none):/#
+    root@(none):/# ls ~
     IDAPROPASSWORD  go      ida-7.2  projects
     bin             gopath  papers   salishan2019random  snap
     root@(none):/# exit
@@ -451,7 +451,7 @@ rootfs on /tmp/local type rootfs (rw,size=506712k,nr_inodes=126678)
 127.0.0.1 on /bin type 9p (rw,nosuid,nodev,relatime,sync,dirsync,uname=rminnich,access=client,msize=65536,trans=fd,rfd=9,wfd=9)
 127.0.0.1 on /etc type 9p (rw,nosuid,nodev,relatime,sync,dirsync,uname=rminnich,access=client,msize=65536,trans=fd,rfd=9,wfd=9)
 127.0.0.1 on /home type 9p (rw,nosuid,nodev,relatime,sync,dirsync,uname=rminnich,access=client,msize=65536,trans=fd,rfd=9,wfd=9)
-root@192:/home/cpubinaries# 
+root@192:/home/cpubinaries#
 ```
 
 As you can see, `/tmp/cpu` is mounted via 9p back to the `cpu` client (recall

dut/README.md

@@ -3,7 +3,7 @@
 Points of contact: [Ron Minnich](https://github.com/rminnich)
 
 DUT is a simple Device Under Test program that gives you control of a node. It is intended to make
-very fast startup and control easy. 
+very fast startup and control easy.
 
 DUT is one program implementing three operations. The first, tester, is run on a test control system, such as your desktop;
 the second, called device, is run on the device; the third, called ssh and also run on the device, starts an
@@ -12,7 +12,7 @@ ssh server assuming one is present.
 DUT is intended to be very limited, with more sophisticated operations, should they be
 needed, being done over SSH.
 
-DUT is found at github.com:linuxboot/dut. 
+DUT is found at github.com:linuxboot/dut.
 
 This chapter describes how we build and use DUT.
 
@@ -65,15 +65,15 @@ Each of these RPCs takes arguments and returns a result, with Welcome being the
 ______________
 < welcome to DUT >
   --------------
-         \   ^__^ 
+         \   ^__^
           \  (oo)\_______
              (__)\       )\/\
                  ||----w |
                  ||     ||
 ```
 
 The current tester mode performs an RPC sequence I use for DXE cleaning, namely, a Welcome, followed by a Reboot, followed
-by a Welcome. This sequence verifies that I can get network going from power on, do a reboot, and reconnect after 
+by a Welcome. This sequence verifies that I can get network going from power on, do a reboot, and reconnect after
 a reboot. It's been good for finding out if a particular DXE can be removed.
 
 Once the second Welcome has happened, if an sshd is installed, it will have been started, and you can do additional commands.

getting_started/README.md

@@ -48,7 +48,7 @@ You will see the following:
 /#
 ```
 
-You can type uname: 
+You can type uname:
 
 ```
 /# uname

intro/README.md

@@ -28,7 +28,7 @@ LinuxBoot brings up the Linux kernel as a DXE in flash ROM instead of the UEFI s
 When Linux boots it needs a root file system with utilities. One such root filesystem used for Linuxboot is based on u-root standard utilities written in Go. The following diagram shows the current state of the UEFI boot process and what is planned for the transition to LinuxBoot.
 
 
-## 
+##
 
 ![image](../images/UEFI-versus-LinuxBoot.svg)
 
@@ -37,11 +37,11 @@ When Linux boots it needs a root file system with utilities. One such root files
 
 Go is a systems programming language created by Google. Go has strong typing, language level support for concurrency, inter-process communication via channels, runtime type safety and other protective measures, dynamic allocation and garbage collection, and closures. Go has a package syntax similar to Java that makes it easy to determine what packages a given program needs.
 
-The modern language constructs make Go a much safer language than C. This safety is critical for network-attached embedded systems, which usually have network utilities written in C, including web servers, network servers including sshd, and programs that provide access to a command interpreter, itself written in C. All are proving to be vulnerable to the attack-rich environment that the Internet has become. 
+The modern language constructs make Go a much safer language than C. This safety is critical for network-attached embedded systems, which usually have network utilities written in C, including web servers, network servers including sshd, and programs that provide access to a command interpreter, itself written in C. All are proving to be vulnerable to the attack-rich environment that the Internet has become.
 
 Even the most skilled programmers make simple mistakes that in C can be fatal, especially on network connected systems. Currently, even the lowest-level firmware in our PCs, printers, and thermostats is network-connected. These programming mistakes are either impossible to make in Go or, if made, are detected at runtime and result in the program exiting.
 
-The case for using a high-level, safe language like Go in very low level embedded firmware might be stronger than for user programs, because exploits at the firmware level are nearly impossible to detect and mitigate. 
+The case for using a high-level, safe language like Go in very low level embedded firmware might be stronger than for user programs, because exploits at the firmware level are nearly impossible to detect and mitigate.
 
 The challenge to using Go in a storage-constrained environment such as firmware is that advanced language features lead to big binaries. Even a date program is about 2 MiB. One Go binary, implementing one function, is twice as large as a BusyBox binary implementing many functions. Currently, a typical BIOS FLASH part is 16 MiB. Fitting many Go binaries into a single BIOS flash part is not practical. The Go compiler is very fast and its sheer speed suggests a solution of having programs compiled only when they are used. With this approach, you can build a root file system that has almost no binaries except the Go compiler itself. The compiled programs and packages can be saved to a RAM-based file system. Another solution is to compile everything together into one BusyBox-style program. There are also other solutions that involve fetching things over the network, but compiling dynamically with Go or creating a BusyBox program are the recommended solutions.
 

u-root/README.md

@@ -39,11 +39,11 @@ All Unix systems start an init process on boot and u-root is no exception. The i
 
 The src directory is where programs and u-root packages reside. The go/bin directory is for any Go tools built after boot; the go/pkg/tool directory contains binaries for various architecture/kernel combinations. The directory in which a compiler toolchain is placed provides information about the target OS and architecture, for example, the Go build places binaries for Linux on x86 64 in `/go/pkg/tool/linux` `amd64/`. Note that there is no `/bin` or many of the other directories expected in a root file system. The init binary builds them. It creates an empty `/bin` which is filled with binaries on demand as shown in Table 2.The u-root root file system has very little state.
 
-For most programs to work, the file system must be more complete. Image space is saved by having init create additional file system structure at boot time: it fills in the missing parts of the root filesystem. It creates `/dev` and `/proc` and mounts them. It creates an empty `/bin` which is filled with binaries on demand. 
+For most programs to work, the file system must be more complete. Image space is saved by having init create additional file system structure at boot time: it fills in the missing parts of the root filesystem. It creates `/dev` and `/proc` and mounts them. It creates an empty `/bin` which is filled with binaries on demand.
 
 In addition to `/bin`, there is a directory called `/buildbin`. `Buildbin` and the correct setup of $PATH are the keys to making on-demand compilation work. The init process sets $PATH to `/go/bin:/bin:/buildbin:/usr/local/bin`. Init also builds `installcommand` using the Go bootstrap builder and creates a complete set of symlinks. As a final step, init execs `sh`.
 
-There is no `/bin/sh` at this point; the first `sh` found in $PATH is `/buildbin/sh`. This is a symlink to `installcommand`. `Installcommand`, once started, examines argv[0], which is `sh`, and takes this as instruction to build `/src/cmds/sh/.go` into `/bin` and then exec `/bin/sh`. There is no difference between starting the first shell and any other program. Hence, part of the boot process involves the construction of an installation tool to build a binary for a shell which is then run. 
+There is no `/bin/sh` at this point; the first `sh` found in $PATH is `/buildbin/sh`. This is a symlink to `installcommand`. `Installcommand`, once started, examines argv[0], which is `sh`, and takes this as instruction to build `/src/cmds/sh/.go` into `/bin` and then exec `/bin/sh`. There is no difference between starting the first shell and any other program. Hence, part of the boot process involves the construction of an installation tool to build a binary for a shell which is then run.
 
 If a user wants to examine the source to the shell, they can `cat` `/src/cmds/sh/.go`. The `cat` command will be built and then show those files. U-root is intended for network-based devices and hence good network initialization code is essential. U-root includes a Go version of the IP and DHCP programs, along with the docker netlink package and a DHCP package.
 
@@ -161,7 +161,7 @@ U-root provides a shell that is stripped down to the fundamentals: it can read c
 
 The shell has several builtin commands, and you can extend it with builtin commands of your own. First, you need to understand the basic source structure of u-root shell builtins. Then, you will learn about user-defined builtins.
 
-All shell builtins, including the ones that come with the shell by default, are written with a standard Go init pattern which installs one or more builtins. 
+All shell builtins, including the ones that come with the shell by default, are written with a standard Go init pattern which installs one or more builtins.
 
 Builtins in the shell are defined by a name and a function. One or more builtins can be described in a source file. The name is kept in a map and the map is searched for a command name before looking in the file system. The function must accept a string as a name and a (possibly zero-length) array of string arguments, and return an error. In order to connect the builtin to the map, a programmer must provide an `init` function which adds the name and function to the map. The `init` function is special in that it is run by Go when the program starts up. In this case, the `init` function just installs a builtin for the time command.