5 sec boot

[C. Scott Ananian]

Some comments:

 - some people have made arguments assuming that "IO time" is
separable from "CPU time".  In the current hardware, we need to busy
wait for IO in Linux (long story, ask dwmw2, basically the delay
required by the hardware is short enough that it slows down IO by
tenfold if we have to pay for a context switch).  So there is no
benefit to be had there, let's not waste effort looking for one.  This
is also the reason there is very little "parallelism" to be had in our
boot path.

 - combined initramfs + kernel is desirable for signed images from a
security standpoint. there's no inherent difficulty here; just
coordination costs.  i don't have strong feelings about what's done in
the unsigned image, although i'd obviously prefer that the signed and
unsigned kernels and bit-for-bit identical, because testing signed
images is inevitably delayed until far too late in the release
process.

 - our initramfs doesn't do much (any) security work in the common
case.  (Mitch pushed me hard on that at design time!)  It *does*
handle mounting filesystems, which is "interesting" (but not costly)
due to the multiple-image upgrade strategy we use.  Separating the
multiple images into separate partitions is undesirable because then
we are unable to re-use common files between the images.  (One could
argue that our Fedora base churns so much that we're not actually
reusing much space; I'd be interested in seeing the numbers pro or
con.)  Separating /root and /home *is* desirable (and in the plan of
record, see below).

 - In any case, most of the initramfs time is spent mounting jffs2.
ubifs should help a lot here.  Not much can really be done for jffs2;
it's a fundamental design limitation.

- Separating the boot and root partition is clearly the way we're
going to go (hopefully for 9.1), and the issue will be forced, as cjb
notes, by our desire to move to ubifs, especially for larger flash
sizes.  There are real hairballs involved in keeping boot and root
properly synchronized during an upgrade so that switchovers are atomic
and there's no point at which an unplanned powerdown will render the
machine unbootable.  Using romfs for /boot makes this very hard, since
you have to rewrite the entire romfs image to add new files.  The
http://wiki.laptop.org/go/Early_boot page outlines the current "plan
of record", but IIRC when I was implementing that (in an olpcrd
branch) I ran into some practical issues which required some
rethinking.  One major change was separating the 'boot' and 'security'
partitions, which isn't done yet on the [[Early boot]] page (or the
olpcrd), but I think *is* implemented already in OFW.  That helps a
lot, and I think some of the complexity in [[Early boot]] can go away
now that that's done.
 --scott

-- 
                         ( http://cscott.net/ )