doc: Update Preparing to Use the Bootstrap Binaries.

* doc/guix.texi (Preparing to Use the Bootstrap Binaries): Mention
bootstrap-mes alongside bootstrap-gcc.
(Reducing the Set of Bootstrap Binaries): Mention the Reduced Binary Seed
bootstrap, MesCC-Tools and Mes.

1 files changed, 39 insertions, 17 deletions

diff --git a/doc/guix.texi b/doc/guix.texi
index d77788c4e0..41abfa4999 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -23920,8 +23920,8 @@ GNU C Library (@pxref{Bootstrapping}).  Usually, these bootstrap binaries are
 Taking these binaries for granted means that we consider them to be a correct
 and trustworthy `seed' for building the complete system.  Therein lies a
 problem: the current combined size of these bootstrap binaries is about 250MB
-(@pxref{Bootstrappable Builds,,, mes, Mes Reference Manual}).  Auditing or
-even inspecting these is next to impossible.
+(@pxref{Bootstrappable Builds,,, mes, GNU Mes}).  Auditing or even inspecting
+these is next to impossible.
 
 For @code{i686-linux} and @code{x86_64-linux}, Guix now features a ``Reduced
 Binary Seed'' bootstrap @footnote{We would like to say: ``Full Source
@@ -23931,8 +23931,8 @@ to use that term for what we do now.}.
 The Reduced Binary Seed bootstrap removes the most critical tools---from a
 trust perspective---from the bootstrap binaries: GCC, Binutils and the GNU C
 Library are replaced by: @code{mescc-tools-seed} (a tiny assembler and linker)
-@code{mes-seed} (a small Scheme Interpreter and a C compiler writen in Scheme)
-and @code{tinycc-seed} (the Mes C Library, built for TinyCC).  Using these new
+@code{bootstrap-mes} (a small Scheme Interpreter and a C compiler writen in
+Scheme and the Mes C Library, built for TinyCC and for GCC).  Using these new
 binary seeds and a new set of
 @c
 packages@footnote{@c
@@ -23988,7 +23988,15 @@ packages bootstrap)} module.  A similar figure can be generated with
 @example
 guix graph -t derivation \
   -e '(@@@@ (gnu packages bootstrap) %bootstrap-gcc)' \
-  | dot -Tps > t.ps
+  | dot -Tps > gcc.ps
+@end example
+
+or, for the Reduced Binary Seed bootstrap
+
+@example
+guix graph -t derivation \
+  -e '(@@@@ (gnu packages bootstrap) %bootstrap-mes)' \
+  | dot -Tps > mes.ps
 @end example
 
 At this level of detail, things are
@@ -24020,10 +24028,10 @@ write them in an output directory with the right layout.  This
 corresponds to the @code{#:modules} argument of
 @code{build-expression->derivation} (@pxref{Derivations}).
 
-Finally, the various tarballs are unpacked by the
-derivations @code{gcc-bootstrap-0.drv}, @code{glibc-bootstrap-0.drv},
-etc., at which point we have a working C tool chain.
-
+Finally, the various tarballs are unpacked by the derivations
+@code{gcc-bootstrap-0.drv}, @code{glibc-bootstrap-0.drv}, or
+@code{bootstrap-mes-0.drv} and @code{mescc-tools-boot-0.drv}, at which point
+we have a working C tool chain.
 
 @unnumberedsubsec Building the Build Tools
 
@@ -24089,7 +24097,9 @@ automated way to produce them, should an update occur, and this is what
 the @code{(gnu packages make-bootstrap)} module provides.
 
 The following command builds the tarballs containing the bootstrap
-binaries (Guile, Binutils, GCC, libc, and a tarball containing a mixture
+binaries (Binutils, GCC, glibc, for the traditional bootstrap and
+linux-libre-headers, mescc-tools-seed, bootstrap-mes for the Reduced
+Binary Seed bootstrap, and Guile, and a tarball containing a mixture
 of Coreutils and other basic command-line tools):
 
 @example
@@ -24108,12 +24118,12 @@ know.
 
 @unnumberedsubsec Reducing the Set of Bootstrap Binaries
 
-Our bootstrap binaries currently include GCC, Guile, etc.  That's a lot
-of binary code!  Why is that a problem?  It's a problem because these
-big chunks of binary code are practically non-auditable, which makes it
-hard to establish what source code produced them.  Every unauditable
-binary also leaves us vulnerable to compiler backdoors as described by
-Ken Thompson in the 1984 paper @emph{Reflections on Trusting Trust}.
+Our traditional bootstrap includes GCC, GNU Libc, Guile, etc.  That's a lot of
+binary code!  Why is that a problem?  It's a problem because these big chunks
+of binary code are practically non-auditable, which makes it hard to establish
+what source code produced them.  Every unauditable binary also leaves us
+vulnerable to compiler backdoors as described by Ken Thompson in the 1984
+paper @emph{Reflections on Trusting Trust}.
 
 This is mitigated by the fact that our bootstrap binaries were generated
 from an earlier Guix revision.  Nevertheless it lacks the level of
@@ -24125,7 +24135,19 @@ The @uref{http://bootstrappable.org, Bootstrappable.org web site} lists
 on-going projects to do that.  One of these is about replacing the
 bootstrap GCC with a sequence of assemblers, interpreters, and compilers
 of increasing complexity, which could be built from source starting from
-a simple and auditable assembler.  Your help is welcome!
+a simple and auditable assembler.
+
+Our first major achievement is the replacement of of GCC, the GNU C Library
+and Binutils by MesCC-Tools (a simple hex linker and macro assembler) and Mes
+(@pxref{Top, GNU Mes Reference Manual,, mes, GNU Mes}, a Scheme interpreter
+and C compiler in Scheme).  Neither MesCC-Tools nor Mes can be fully
+bootstrapped yet and thus we inject them as binary seeds.  We call this the
+Reduced Binary Seed bootstrap, as it has halved the size of our bootstrap
+binaries!  Also, it has eliminated the C compiler binary; i686-linux and
+x86_64-linux Guix packages are now bootstrapped without any binary C compiler.
+
+Work is ongoing to make MesCC-Tools and Mes fully bootstrappable and we are
+also looking at any other bootstrap binaries.  Your help is welcome!
 
 @node Porting
 @section Porting to a New Platform