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/ ) _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel