Re: 5 sec boot
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
Re: 5 sec boot
mitch wrote: On a related topic, I would like to see us start bundling the initrd into the kernel image. It's certainly possible to do that with existing into? i'd rather see it simply concatenated, By into, I mean in the same file. The existing kernel mechanism that I have looked at involves using the linker to bind the kernel with the initramfs, creating symbols that tell the kernel the location and size. See Documentation/filesystems/ramfs-roofs-initramfs.txt , especially the Populating initramfs: section. I don't have strong feelings about the mechanism that is used. The method that is already in the kernel source seems like a good choice unless it has problems. i think a scheme which makes the kernel and initrd inseparable using tools available on the laptop wouldn't be optimal. like you, i like having them in the same file, but if we can't figure out how to glue an external initramfs onto a kernel so that they can still be taken apart (so the initramfs can be easily modified, or perhaps reused with another kernel, easily), then i'd say we should go with deepak's suggestion of separate partitions for kernel and initrd. (this all assumes the performance win over simply reading from the filesystem is worth it, of course. i'm currently assuming that it would be, even with a possible change in filesystem.) paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On 04/10/08 18:07 -0700, Deepak Saxena wrote: - Embedded systems often use a suspend image to speedup boottime. Basically load an image into memory and then jump into the kernel as if we are resuming from firmware. Another approach if we can't do a full suspend image this is to use the new container code and save the runtime of the user session so we can just reload it. Both these methods require flash space... ++ - A suspend image would really help. The only gotcha is (as always), USB. You would probably need to create an image without any USB devices attached, and then let probing take over after you have resumed. There are several successful embedded solutions that use snapshot images to great effect. We should borrow liberally from their ideas. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Mon, 6 Oct 2008, [EMAIL PROTECTED] wrote: mitch wrote: On a related topic, I would like to see us start bundling the initrd into the kernel image. It's certainly possible to do that with existing into? i'd rather see it simply concatenated, By into, I mean in the same file. The existing kernel mechanism that I have looked at involves using the linker to bind the kernel with the initramfs, creating symbols that tell the kernel the location and size. See Documentation/filesystems/ramfs-roofs-initramfs.txt , especially the Populating initramfs: section. I don't have strong feelings about the mechanism that is used. The method that is already in the kernel source seems like a good choice unless it has problems. i think a scheme which makes the kernel and initrd inseparable using tools available on the laptop wouldn't be optimal. like you, i like having them in the same file, but if we can't figure out how to glue an external initramfs onto a kernel so that they can still be taken apart (so the initramfs can be easily modified, or perhaps reused with another kernel, easily), then i'd say we should go with deepak's suggestion of separate partitions for kernel and initrd. it's not that hard to find where the filesystem image starts and extract/replace/modify it from there. Tivo systems have been doing this for a _long_ time. they have two kernel partitions, two root partitions, etc with the kernel partition including the initial filesystem and the firmware checking the integrity of the kernel partition (and the software there checks the integrity of the root filesystem) it works well for Tivo in the locked-down mode, and it's been easy for people to hack it once the firmware check is disabled David Lang (this all assumes the performance win over simply reading from the filesystem is worth it, of course. i'm currently assuming that it would be, even with a possible change in filesystem.) paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Oct 05 2008, at 10:50, Jim Gettys was caught saying: On Sat, 2008-10-04 at 16:32 -1000, Mitch Bradley wrote: I have considered something like that off and on. It's sort of nice to have a definite length for the images. There are ways around that, but they are a bit ugly at some level. It's sort of a tossup at some level. One difficultly with having a lot of partitions is that it makes it more likely that you will encounter the resizing issue. Ubifs is built on the Ubi layer, which handles resizing (and does so in the face of flash errors). UBI may handle resizeable volumes but I think for our use case, we want static volume sizes. http://www.linux-mtd.infradead.org/doc/ubi.html#L_autoresize Then again, since ubifs mounts quickly, the largest reason for partitioning we've had (to reduce boot time) evaporates. There may be other reasons to want partitioning, given dynamic resizing a'la lvm, however. If we go to non-bare flash, of course, other solutions will have to be found. We'll still need to support existing deployed laptops so I see the what type of flash do we use in future updates problem as orthogonal to replacing the filesystem on current HW. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Sat, 2008-10-04 at 16:32 -1000, Mitch Bradley wrote: I have considered something like that off and on. It's sort of nice to have a definite length for the images. There are ways around that, but they are a bit ugly at some level. It's sort of a tossup at some level. One difficultly with having a lot of partitions is that it makes it more likely that you will encounter the resizing issue. Ubifs is built on the Ubi layer, which handles resizing (and does so in the face of flash errors). http://www.linux-mtd.infradead.org/doc/ubi.html#L_autoresize Then again, since ubifs mounts quickly, the largest reason for partitioning we've had (to reduce boot time) evaporates. There may be other reasons to want partitioning, given dynamic resizing a'la lvm, however. If we go to non-bare flash, of course, other solutions will have to be found. - Jim -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Sat, 4 Oct 2008, Mitch Bradley wrote: Deepak Saxena wrote: On Oct 03 2008, at 07:34, Mitch Bradley was caught saying: If it is stored deocompressed to begin with on the filesystem, we can simply read it into mem from flash and run. This would require a few extra MiB of flash. Granted, reading from flash is slower than reading from memory, so we may not see a a net benefit. Easy enough to test... Some rules of thumb for OLPC: a) Memory copy goes at about 500 MB/sec (so can be neglected in this case) b) zlib decompression goes at about 3 MB/sec for typical code (2:1 compression ratio) (Over the complete filesystem, JFFS2's automatic zlib compression gets you about 3:2 space savings, because of various overhead factors). c) Raw FLASH read time maxes out at 20 MB/sec. But you don't get that speed from the filesystem; JFFS2 is good for between 5 and 10 MB/sec. Considering all the intricacies of JFFS2, my best guess is that it's going to be close to a wash whether the kernel + initrd is stored in compressed or uncompressed form. OTOH, if the kernel + initrd were in a separate partition in e.g. romfs format, where OFW could just blast them into memory without doing JFFS2 node processing, we could probably get close to the 20 MB/sec speed. Another holdup is the time it takes to do the hash calculation for security checking. That costs a couple of seconds. Ivan and I worked pretty hard to minimize that time, choosing one of the faster hash functions. can you do the hash as you copy it? it should be pretty close to free at that point (since the CPU is waiting for memory/flash access it can do the hash calculationwhen it would otherwise be stalled) David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
can you do the hash as you copy it? it should be pretty close to free at that point (since the CPU is waiting for memory/flash access it can do the hash calculationwhen it would otherwise be stalled) According to my measurements the GeodeLX can fetch a new cache line (32 bytes) every 20-25 clocks. Unless you can do the hash 2 clocks/byte then you will only earn the looping time (assuming that the hashed blocks fit into the L1 cache). ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Sun, 5 Oct 2008, NoiseEHC wrote: can you do the hash as you copy it? it should be pretty close to free at that point (since the CPU is waiting for memory/flash access it can do the hash calculationwhen it would otherwise be stalled) According to my measurements the GeodeLX can fetch a new cache line (32 bytes) every 20-25 clocks. Unless you can do the hash 2 clocks/byte then you will only earn the looping time (assuming that the hashed blocks fit into the L1 cache). is that speed reading from ram or from flash? David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
Hi, Then again, since ubifs mounts quickly, the largest reason for partitioning we've had (to reduce boot time) evaporates. There may be other reasons to want partitioning, given dynamic resizing a'la lvm, however. You don't mention the fundamental reason that we need partitioning if we go to ubifs: we need OFW to be able to boot the system, and it doesn't have an ubifs driver. - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Sun, 5 Oct 2008, NoiseEHC wrote: can you do the hash as you copy it? it should be pretty close to free at that point (since the CPU is waiting for memory/flash access it can do the hash calculationwhen it would otherwise be stalled) According to my measurements the GeodeLX can fetch a new cache line (32 bytes) every 20-25 clocks. Unless you can do the hash 2 clocks/byte then you will only earn the looping time (assuming that the hashed blocks fit into the L1 cache). is that speed reading from ram or from flash? DDR RAM, if neither the L1 nor L2 was hit. I did not measure raw NAND read speed, I do not even know how to begin with it. see: http://wiki.laptop.org/go/Geode_LX#Memory.2C_Cache_and_TLB ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
There is a C routine available for doing the initial read from the file system. We don't have to do it from scratch... Bull. Flag. Red - Jim On Sun, 2008-10-05 at 13:00 -0400, Chris Ball wrote: Hi, Then again, since ubifs mounts quickly, the largest reason for partitioning we've had (to reduce boot time) evaporates. There may be other reasons to want partitioning, given dynamic resizing a'la lvm, however. You don't mention the fundamental reason that we need partitioning if we go to ubifs: we need OFW to be able to boot the system, and it doesn't have an ubifs driver. - Chris. -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
Memory to memory copy: 500 MB/s Raw NAND FLASH read:20 MB/s Security hash: 4 MB/s So overlapping hash calculation with NAND FLASH read is of limited value, and trying to overlap anything with memory copy is almost certainly counterproductive. This discussion seem to be degenerating into a brainstorming session about an sub-problem that is pretty well under control (the firmware component of the boot time). I've been working diligently on that sub-problem for nearly 2 years now, and I think I have an excellent grasp of where the cycles are going and what can be done to improve it. The only significant opportunity at this point is to reduce the JFFS2 time, which will require either partitioning or abandoning JFFS2 for the boot files, or both. UBI+UBIFS is one workable approach in the context of a Linux-only machine. There are some others, such as Redboot partitions with a small boot partition and a large system partition, with various FS possibilities for the two partitions. The quickest path to a deliverable system would be Redboot + JFFS2 boot partition + UBI system partition. The rest of the fruit on the tree is solidly in the OS domain, encompassing kernel startup, userland startup/initscripts, X startup, and Sugar / application startup. I would encourage each of you to address the areas in which you have special expertise, and then to take action. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
When I will finally have some time (currently I am working even on weekends) I will finish my half made zlib decompression code. Where is that Security hash's code? Mitch Bradley wrote: Memory to memory copy: 500 MB/s Raw NAND FLASH read:20 MB/s Security hash: 4 MB/s So overlapping hash calculation with NAND FLASH read is of limited value, and trying to overlap anything with memory copy is almost certainly counterproductive. This discussion seem to be degenerating into a brainstorming session about an sub-problem that is pretty well under control (the firmware component of the boot time). I've been working diligently on that sub-problem for nearly 2 years now, and I think I have an excellent grasp of where the cycles are going and what can be done to improve it. The only significant opportunity at this point is to reduce the JFFS2 time, which will require either partitioning or abandoning JFFS2 for the boot files, or both. UBI+UBIFS is one workable approach in the context of a Linux-only machine. There are some others, such as Redboot partitions with a small boot partition and a large system partition, with various FS possibilities for the two partitions. The quickest path to a deliverable system would be Redboot + JFFS2 boot partition + UBI system partition. The rest of the fruit on the tree is solidly in the OS domain, encompassing kernel startup, userland startup/initscripts, X startup, and Sugar / application startup. I would encourage each of you to address the areas in which you have special expertise, and then to take action. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
NoiseEHC wrote: When I will finally have some time (currently I am working even on weekends) I will finish my half made zlib decompression code. To what end? AFAIK the zlib decompression (both in OFW and in the OS) is not one of the primary problem areas. Where is that Security hash's code? The computation code is at http://dev.laptop.org/git?p=bios-crypto . It is based on LibTomCrypt. The specific hashes and signatures that we use are detailed in the Computation column of http://wiki.laptop.org/go/Firmware_security#Summary The security computation code has undergone an audit by outside security experts. Any changes to the core code would require an additional audit. Mitch Bradley wrote: Memory to memory copy: 500 MB/s Raw NAND FLASH read:20 MB/s Security hash: 4 MB/s So overlapping hash calculation with NAND FLASH read is of limited value, and trying to overlap anything with memory copy is almost certainly counterproductive. This discussion seem to be degenerating into a brainstorming session about an sub-problem that is pretty well under control (the firmware component of the boot time). I've been working diligently on that sub-problem for nearly 2 years now, and I think I have an excellent grasp of where the cycles are going and what can be done to improve it. The only significant opportunity at this point is to reduce the JFFS2 time, which will require either partitioning or abandoning JFFS2 for the boot files, or both. UBI+UBIFS is one workable approach in the context of a Linux-only machine. There are some others, such as Redboot partitions with a small boot partition and a large system partition, with various FS possibilities for the two partitions. The quickest path to a deliverable system would be Redboot + JFFS2 boot partition + UBI system partition. The rest of the fruit on the tree is solidly in the OS domain, encompassing kernel startup, userland startup/initscripts, X startup, and Sugar / application startup. I would encourage each of you to address the areas in which you have special expertise, and then to take action. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
To what end? AFAIK the zlib decompression (both in OFW and in the OS) is not one of the primary problem areas. Changing fs read from CPU bound to IO bound would change a lot of things, for example the boot could utilize a little bit of more concurrency. Unfortunately we will only see its effect when the code is written (or we will see that it does not help). It is not a problem area but first there are projects which would gain on this speed (like etoys loading AFAIK), and second every speed optimization (like boot time and activity launch time) should take into consideration the faster reading speed (which is theoretical at this point). See, I am NOT suggesting that you should waste time on these nonproblems but I am not a Linux programming expert so I simply cannot help you at this time (finishing 8.2.0) so I spend my (currently not existing) time on these nonproblem projects. Where is that Security hash's code? The computation code is at http://dev.laptop.org/git?p=bios-crypto . It is based on LibTomCrypt. The specific hashes and signatures that we use are detailed in the Computation column of http://wiki.laptop.org/go/Firmware_security#Summary The security computation code has undergone an audit by outside security experts. Any changes to the core code would require an additional audit. Exactly which algorithm does the firmware use and how much data does it hash? Just out of curiosity... ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
mitch wrote: Deepak Saxena wrote: On Oct 04 2008, at 15:49, Mitch Bradley was caught saying: c) Raw FLASH read time maxes out at 20 MB/sec. But you don't get that speed from the filesystem; JFFS2 is good for between 5 and 10 MB/sec. Considering all the intricacies of JFFS2, my best guess is that it's going to be close to a wash whether the kernel + initrd is stored in compressed or uncompressed form. OTOH, if the kernel + initrd were in a separate partition in e.g. romfs format, where OFW could just blast them into memory without doing JFFS2 node processing, we could probably get close to the 20 MB/sec speed. We can probably just get away with making all of /boot into a romfs; however, do we even need to bother with a filesystem representation of the images? We could have four partions (kernel0, kernel1, initrd0, initrd1) that contain the binary data for current and alternate images and some sort of way to tell which one is current and which one is alternate. +1. there's no need for the primary kernel to be in the rootfs on this platform, that i can see, as long as there's a choice when booting for getting at non-primary kernels, whether in a secondary partition, or in the rootfs or other storage. i'm sure OFW is capable of giving us such a choice. :-) ~Deepak I have considered something like that off and on. It's sort of nice to have a definite length for the images. There are ways around that, but they are a bit ugly at some level. It's sort of a tossup at some level. reading a header of some sort (for the size), then the image, doesn't seem all that ugly to me. (maybe i misunderstand you.) One difficultly with having a lot of partitions is that it makes it more likely that you will encounter the resizing issue. i'd think the amount of flash we'd lose by making a couple of kernel+initrd partitions (or maybe we only need one) that were big enough to hold foreseeable needs (e.g., current size + 50%) would be pretty small. On a related topic, I would like to see us start bundling the initrd into the kernel image. It's certainly possible to do that with existing into? i'd rather see it simply concatenated, unless the tools to insert an initrd into the kernel are trivial, and allow repackaging with a different initrd in a trivial manner. my experience has been with the mkimage tool that comes with uboot -- it's a simple blob encapsulator, and lets you repackage your kernel pretty simply. since you always need the two pieces together, pulling them out as one seems to make sense. after concatenating the two, dd the result into a flash partition, and you're done. paul kernel mechanisms. The two pieces are interdependent enough that they really have to be updated together, at which point it's really better to have them in the same image. =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
NoiseEHC wrote: To what end? AFAIK the zlib decompression (both in OFW and in the OS) is not one of the primary problem areas. Changing fs read from CPU bound to IO bound would change a lot of things, for example the boot could utilize a little bit of more concurrency. Unfortunately we will only see its effect when the code is written (or we will see that it does not help). It is not a problem area but first there are projects which would gain on this speed (like etoys loading AFAIK), and second every speed optimization (like boot time and activity launch time) should take into consideration the faster reading speed (which is theoretical at this point). See, I am NOT suggesting that you should waste time on these nonproblems but I am not a Linux programming expert so I simply cannot help you at this time (finishing 8.2.0) so I spend my (currently not existing) time on these nonproblem projects. Where is that Security hash's code? The computation code is at http://dev.laptop.org/git?p=bios-crypto . It is based on LibTomCrypt. The specific hashes and signatures that we use are detailed in the Computation column of http://wiki.laptop.org/go/Firmware_security#Summary The security computation code has undergone an audit by outside security experts. Any changes to the core code would require an additional audit. Exactly which algorithm does the firmware use and how much data does it hash? Just out of curiosity... The algorithms are as specified in the wiki reference. The hashed data includes the kernel and the initrd, about 4 megabytes total. You can get the exact numbers for a given OS release by looking at the sizes of /boot/ros.zip and /boot/rd.zip ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On a related topic, I would like to see us start bundling the initrd into the kernel image. It's certainly possible to do that with existing into? i'd rather see it simply concatenated, By into, I mean in the same file. The existing kernel mechanism that I have looked at involves using the linker to bind the kernel with the initramfs, creating symbols that tell the kernel the location and size. See Documentation/filesystems/ramfs-roofs-initramfs.txt , especially the Populating initramfs: section. I don't have strong feelings about the mechanism that is used. The method that is already in the kernel source seems like a good choice unless it has problems. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Oct 03 2008, at 08:08, Mitch Bradley was caught saying: neither of these require any changes to the Fedora stuff (I do this on every system that I run, have done so with many different distros, and never run into problems) remember that you can still have modules for USB devices, but not need to use any of them at boot time (if there are no USB devices plugged in) As mentioned, our wireless module is on an internal USB port. To what extent does that complicate the situation? With the module_init_deffered() stuff we can move the init of the libertas out of the critical path. The reason we modularized USB AFAIK is to keep it out of the resume path when not in used but I forget that there is also a bind/unbind to driver functionality that can be used to to achieve the same. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
a) Some people argue that we shouldn't bother to speed up boot, because suspend/resume optimization is more important. (I agree that S/R is more important, but I wish that we could do both.) Thank you all for your work on cutting down boot times. I am interested in the use case where a student does not have a lap top they can carry with them, but does have access to computer labs at school, in the library, at after-school day-care, and has a family computer at home. This is true for many US students. We are looking at putting Sugar onto a USB key so that students can boot up any of these computers to be their Sugar system as they move from place to place. Clearly boot-time will be critical. Also the machine may, or may not, change between boots so I think that cuts down some of the short-cuts you can take. The basics aren't working yet for the USB boot so this isn't a request to work on this boot speed issue right now, but it would be great if while people are thinking about these issues you'd take notes as to which techniques may help reduce boot time from a USB Key. Thanks! Caroline -- Caroline Meeks SchoolKey.org [EMAIL PROTECTED] 617-500-3488 - Office 505-213-3268 - Fax ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Oct 03 2008, at 07:34, Mitch Bradley was caught saying: Could somebody explain me whether [the 5 second boot] results are applicable to the XO, and how far are we from it, please? Ticket http://dev.laptop.org/ticket/4349 details my and codyl's experiments with speeding up boot. Some other ideas: - Right now the firmware copies the uncompressed kernel and initrd to memory and then the kernel and initrd decompressor has to re-read it from memory and write it back out in decompressed format. If it is stored deocompressed to begin with on the filesystem, we can simply read it into mem from flash and run. This would require a few extra MiB of flash. Granted, reading from flash is slower than reading from memory, so we may not see a a net benefit. Easy enough to test... - Embedded systems often use a suspend image to speedup boottime. Basically load an image into memory and then jump into the kernel as if we are resuming from firmware. Another approach if we can't do a full suspend image this is to use the new container code and save the runtime of the user session so we can just reload it. Both these methods require flash space... ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
Deepak Saxena wrote: On Oct 03 2008, at 07:34, Mitch Bradley was caught saying: Could somebody explain me whether [the 5 second boot] results are applicable to the XO, and how far are we from it, please? Ticket http://dev.laptop.org/ticket/4349 details my and codyl's experiments with speeding up boot. Some other ideas: - Right now the firmware copies the uncompressed kernel and initrd to memory and then the kernel and initrd decompressor has to re-read it from memory and write it back out in decompressed format. Actually, OFW decompresses them both, so by the time control is transferred to the kernel, both kernel and initrd are already in the clear. But the principle is the same. Somebody has to do the decompression. OFW's decompression code is essentially the same as the kernel's, derived from the Mark Adler code. If it is stored deocompressed to begin with on the filesystem, we can simply read it into mem from flash and run. This would require a few extra MiB of flash. Granted, reading from flash is slower than reading from memory, so we may not see a a net benefit. Easy enough to test... Some rules of thumb for OLPC: a) Memory copy goes at about 500 MB/sec (so can be neglected in this case) b) zlib decompression goes at about 3 MB/sec for typical code (2:1 compression ratio) (Over the complete filesystem, JFFS2's automatic zlib compression gets you about 3:2 space savings, because of various overhead factors). c) Raw FLASH read time maxes out at 20 MB/sec. But you don't get that speed from the filesystem; JFFS2 is good for between 5 and 10 MB/sec. Considering all the intricacies of JFFS2, my best guess is that it's going to be close to a wash whether the kernel + initrd is stored in compressed or uncompressed form. OTOH, if the kernel + initrd were in a separate partition in e.g. romfs format, where OFW could just blast them into memory without doing JFFS2 node processing, we could probably get close to the 20 MB/sec speed. Another holdup is the time it takes to do the hash calculation for security checking. That costs a couple of seconds. Ivan and I worked pretty hard to minimize that time, choosing one of the faster hash functions. - Embedded systems often use a suspend image to speedup boottime. Basically load an image into memory and then jump into the kernel as if we are resuming from firmware. Another approach if we can't do a full suspend image this is to use the new container code and save the runtime of the user session so we can just reload it. Both these methods require flash space... It would be nice if we could identify a good common userland starting point and snapshot that. My gut feel is that a 20 MB image might be sufficient. ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
This depends pretty strongly on which Linux distribution you choose as the basis for your USB key Sugar installation. The need to be compatible with a wide range of different computers is going to be a significant issue. If you have to deal with a lot of possibilities, you need a lot of code and that code has to check for a lot of things. That said, there are probably improvements to be had. It's probably best to address the issue with the organization that is responsible for the particular Linux distribution. My work has been specifically focused on what we can do with XO laptops, for which we know the hardware configuration. Caroline Meeks wrote: a) Some people argue that we shouldn't bother to speed up boot, because suspend/resume optimization is more important. (I agree that S/R is more important, but I wish that we could do both.) Thank you all for your work on cutting down boot times. I am interested in the use case where a student does not have a lap top they can carry with them, but does have access to computer labs at school, in the library, at after-school day-care, and has a family computer at home. This is true for many US students. We are looking at putting Sugar onto a USB key so that students can boot up any of these computers to be their Sugar system as they move from place to place. Clearly boot-time will be critical. Also the machine may, or may not, change between boots so I think that cuts down some of the short-cuts you can take. The basics aren't working yet for the USB boot so this isn't a request to work on this boot speed issue right now, but it would be great if while people are thinking about these issues you'd take notes as to which techniques may help reduce boot time from a USB Key. Thanks! Caroline -- Caroline Meeks SchoolKey.org [EMAIL PROTECTED] 617-500-3488 - Office 505-213-3268 - Fax ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Oct 04 2008, at 19:24, Deepak Saxena was caught saying: On Oct 04 2008, at 15:49, Mitch Bradley was caught saying: c) Raw FLASH read time maxes out at 20 MB/sec. But you don't get that speed from the filesystem; JFFS2 is good for between 5 and 10 MB/sec. Considering all the intricacies of JFFS2, my best guess is that it's going to be close to a wash whether the kernel + initrd is stored in compressed or uncompressed form. OTOH, if the kernel + initrd were in a separate partition in e.g. romfs format, where OFW could just blast them into memory without doing JFFS2 node processing, we could probably get close to the 20 MB/sec speed. We can probably just get away with making all of /boot into a romfs; however, do we even need to bother with a filesystem representation of the images? We could have four partions (kernel0, kernel1, initrd0, initrd1) that contain the binary s/binary/raw/ data for current and alternate images and some sort of way to tell which one is current and which one is alternate. ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
Deepak Saxena wrote: On Oct 04 2008, at 15:49, Mitch Bradley was caught saying: c) Raw FLASH read time maxes out at 20 MB/sec. But you don't get that speed from the filesystem; JFFS2 is good for between 5 and 10 MB/sec. Considering all the intricacies of JFFS2, my best guess is that it's going to be close to a wash whether the kernel + initrd is stored in compressed or uncompressed form. OTOH, if the kernel + initrd were in a separate partition in e.g. romfs format, where OFW could just blast them into memory without doing JFFS2 node processing, we could probably get close to the 20 MB/sec speed. We can probably just get away with making all of /boot into a romfs; however, do we even need to bother with a filesystem representation of the images? We could have four partions (kernel0, kernel1, initrd0, initrd1) that contain the binary data for current and alternate images and some sort of way to tell which one is current and which one is alternate. ~Deepak I have considered something like that off and on. It's sort of nice to have a definite length for the images. There are ways around that, but they are a bit ugly at some level. It's sort of a tossup at some level. One difficultly with having a lot of partitions is that it makes it more likely that you will encounter the resizing issue. On a related topic, I would like to see us start bundling the initrd into the kernel image. It's certainly possible to do that with existing kernel mechanisms. The two pieces are interdependent enough that they really have to be updated together, at which point it's really better to have them in the same image. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Oct 04 2008, at 16:32, Mitch Bradley was caught saying: We can probably just get away with making all of /boot into a romfs; however, do we even need to bother with a filesystem representation of the images? We could have four partions (kernel0, kernel1, initrd0, initrd1) that contain the binary data for current and alternate images and some sort of way to tell which one is current and which one is alternate. ~Deepak I have considered something like that off and on. It's sort of nice to have a definite length for the images. There are ways around that, but they are a bit ugly at some level. It's sort of a tossup at some level. One difficultly with having a lot of partitions is that it makes it more likely that you will encounter the resizing issue. +1. I'm also thinking that romfs overhead is minimal enough that it is not going to hurt boottime. On a related topic, I would like to see us start bundling the initrd into the kernel image. It's certainly possible to do that with existing kernel mechanisms. The two pieces are interdependent enough that they really have to be updated together, at which point it's really better to have them in the same image. This is on the packaging todo list; however, if we move to a non-module kernel, then the initramfs contents will be completely independent of the kernel build so we may want to just keep them as separate packages? ~Deepak -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
Deepak Saxena wrote: On Oct 04 2008, at 16:32, Mitch Bradley was caught saying: We can probably just get away with making all of /boot into a romfs; however, do we even need to bother with a filesystem representation of the images? We could have four partions (kernel0, kernel1, initrd0, initrd1) that contain the binary data for current and alternate images and some sort of way to tell which one is current and which one is alternate. ~Deepak I have considered something like that off and on. It's sort of nice to have a definite length for the images. There are ways around that, but they are a bit ugly at some level. It's sort of a tossup at some level. One difficultly with having a lot of partitions is that it makes it more likely that you will encounter the resizing issue. +1. I'm also thinking that romfs overhead is minimal enough that it is not going to hurt boottime. I think that is correct. The redboot partition format could be used to specify the actual length of the images, since it has separate fields for actual size and size on media, but it has enough other problems that I think I'd rather not start depending on it more deeply. On a related topic, I would like to see us start bundling the initrd into the kernel image. It's certainly possible to do that with existing kernel mechanisms. The two pieces are interdependent enough that they really have to be updated together, at which point it's really better to have them in the same image. This is on the packaging todo list; however, if we move to a non-module kernel, then the initramfs contents will be completely independent of the kernel build so we may want to just keep them as separate packages? That might be a help for development, but for signed builds, I still like the idea of one bundle to rule them all. ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
Yes, but our biggest single component of boot time this instant is jffs2 mount (which happens twice during the boot sequence), not covered in that work. This is fixable in two ways; partially, by partitioning the flash (which would remove one mount), or even better, by using Ubifs, which may be ready for widespread use now. The rest of it is mostly stuff that we either don't do or can avoid doing, or have already prototyped (Mitch has had start up scripts in his back pocket that may also be part of the equasion). Deepak has begun work on Ubifs testing... - Jim On Fri, 2008-10-03 at 15:24 +0200, NoiseEHC wrote: If you somehow missed it, there is possible to boot Linux in 5 seconds on an EeePC. http://uk.youtube.com/watch?v=s7NxCM8ryF8 Here is the paper: http://www.fenrus.org/plumbers_fastboot.ppt Could somebody explain me whether these results are applicable to the XO, and how far are we from it, please? -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Fri, Oct 03, 2008 at 03:24:25PM +0200, NoiseEHC wrote: If you somehow missed it, there is possible to boot Linux in 5 seconds on an EeePC. http://uk.youtube.com/watch?v=s7NxCM8ryF8 Here is the paper: http://www.fenrus.org/plumbers_fastboot.ppt Could somebody explain me whether these results are applicable to the XO, and how far are we from it, please? I got TuxOnIce[1] patched[2] and as far as testing the hibernate step[3] before I gave up after TuxOnIce refused to save the image (it just rebooted[4] instead). It's a bit too much of a time sink for me to hope to get much more done on, though. Hopefully someone else can pursue it or alternatives. Martin 1. http://www.tuxonice.net/HOWTO-7.html#ss7.5 2. http://dev.laptop.org/git?p=users/mdengler/olpc-2.6;a=shortlog;h=testing 3. Step #6 in http://lists.laptop.org/pipermail/devel/2008-August/018700.html 4. [unload/unmount stuff] echo 1 /sys/power/tuxonice/keep_image echo 1 /sys/power/tuxonice/freezer_test echo 1 /sys/power/tuxonice/suspend [should just create memory image, but just rebooted right away] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel pgpcPspuXpFXB.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
The following articles on reducing linux boot times have recently been published: http://blog.crozat.net/2008/09/improving-boot-time-on-general-linux.html http://www.bootchart.org/ http://lwn.net/Articles/299483/ http://broadcast.oreilly.com/2008/09/how-powertop-latencytop-and-fi.html There might be some useful ideas / tools mentioned. On Oct 3, 2008, at 8:06 AM, Martin Dengler wrote: On Fri, Oct 03, 2008 at 03:24:25PM +0200, NoiseEHC wrote: If you somehow missed it, there is possible to boot Linux in 5 seconds on an EeePC. http://uk.youtube.com/watch?v=s7NxCM8ryF8 Here is the paper: http://www.fenrus.org/plumbers_fastboot.ppt Could somebody explain me whether these results are applicable to the XO, and how far are we from it, please? I got TuxOnIce[1] patched[2] and as far as testing the hibernate step[3] before I gave up after TuxOnIce refused to save the image (it just rebooted[4] instead). It's a bit too much of a time sink for me to hope to get much more done on, though. Hopefully someone else can pursue it or alternatives. Martin 1. http://www.tuxonice.net/HOWTO-7.html#ss7.5 2. http://dev.laptop.org/git?p=users/mdengler/ olpc-2.6;a=shortlog;h=testing 3. Step #6 in http://lists.laptop.org/pipermail/devel/2008-August/018700.html 4. [unload/unmount stuff] echo 1 /sys/power/tuxonice/keep_image echo 1 /sys/power/tuxonice/freezer_test echo 1 /sys/power/tuxonice/suspend [should just create memory image, but just rebooted right away] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
Could somebody explain me whether [the 5 second boot] results are applicable to the XO, and how far are we from it, please? Ticket http://dev.laptop.org/ticket/4349 details my and codyl's experiments with speeding up boot. Between the two of us, we managed to shave off 23 seconds. We used some techiques similar to those in the 5-second paper - eliminating udev, paring down initscripts. The techniques that we used haven't been deployed for several reasons: a) Some people argue that we shouldn't bother to speed up boot, because suspend/resume optimization is more important. (I agree that S/R is more important, but I wish that we could do both.) b) OLPC's software team is tiny relative to the number of laptops that we are shipping. As a result, we can't diverge from Fedora as much as would be appropriate (considering the extent to which XO diverges from Fedora's target generic PC). We just don't have enough people to maintain a heavily-customized startup sequence. (Some have suggested that parallelized init strategies, as some distros are starting to adopt, is the solution. I disagree, based on my understanding of how the XO hardware works - there is just not much parallelism possible on this hardware.) As jg points out, there is another 14+ seconds available by changing the NAND layout. We could get 7 seconds just by partitioning the NAND, without changing filesystems (support for this has been in OFW since last Christmas). Switching to UBIFS would gain another 7 seconds. Combining all the techniques mentioned in this message would get us down to perhaps 30 seconds (power on to console login prompt), but there is still the issue of X and Sugar startup time. To get close to the 5 second number, we would have to adopt some of the additional techniques cited in the paper, such as non-modular/no-initrd/async-init kernel, deeply-pared initscript, pre-computed XKB configuration, etc. And then there is the problem of Python startup time. We have some techniques to help that, but it's still a factor. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Fri, 3 Oct 2008, Mitch Bradley wrote: Could somebody explain me whether [the 5 second boot] results are applicable to the XO, and how far are we from it, please? Ticket http://dev.laptop.org/ticket/4349 details my and codyl's experiments with speeding up boot. Between the two of us, we managed to shave off 23 seconds. We used some techiques similar to those in the 5-second paper - eliminating udev, paring down initscripts. The techniques that we used haven't been deployed for several reasons: a) Some people argue that we shouldn't bother to speed up boot, because suspend/resume optimization is more important. (I agree that S/R is more important, but I wish that we could do both.) b) OLPC's software team is tiny relative to the number of laptops that we are shipping. As a result, we can't diverge from Fedora as much as would be appropriate (considering the extent to which XO diverges from Fedora's target generic PC). We just don't have enough people to maintain a heavily-customized startup sequence. (Some have suggested that parallelized init strategies, as some distros are starting to adopt, is the solution. I disagree, based on my understanding of how the XO hardware works - there is just not much parallelism possible on this hardware.) As jg points out, there is another 14+ seconds available by changing the NAND layout. We could get 7 seconds just by partitioning the NAND, without changing filesystems (support for this has been in OFW since last Christmas). Switching to UBIFS would gain another 7 seconds. Combining all the techniques mentioned in this message would get us down to perhaps 30 seconds (power on to console login prompt), but there is still the issue of X and Sugar startup time. To get close to the 5 second number, we would have to adopt some of the additional techniques cited in the paper, such as non-modular/no-initrd/async-init kernel, deeply-pared initscript, pre-computed XKB configuration, etc. since the XO hardware is fixed, why would you ship a kernel that used modules for any of the XO hardware? especially for anything that it needs at boot time? if you don't need modules to boot, why do you need initrd? you should be able to just do everything from the main partition. neither of these require any changes to the Fedora stuff (I do this on every system that I run, have done so with many different distros, and never run into problems) remember that you can still have modules for USB devices, but not need to use any of them at boot time (if there are no USB devices plugged in) David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
[EMAIL PROTECTED] wrote: On Fri, 3 Oct 2008, Mitch Bradley wrote: ... since the XO hardware is fixed, why would you ship a kernel that used modules for any of the XO hardware? especially for anything that it needs at boot time? By and large, the required drivers are not modules. It's possible that we might have screwed up in some cases, but I think we've done the right thing for the most part. The built-in wireless device is on USB. if you don't need modules to boot, why do you need initrd? you should be able to just do everything from the main partition. Our activation security system is in an initrd so that the firmware can check its signature before booting it. The whole security thing adds a bunch of interesting wrinkles. neither of these require any changes to the Fedora stuff (I do this on every system that I run, have done so with many different distros, and never run into problems) remember that you can still have modules for USB devices, but not need to use any of them at boot time (if there are no USB devices plugged in) As mentioned, our wireless module is on an internal USB port. To what extent does that complicate the situation? David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Fri, 3 Oct 2008, Mitch Bradley wrote: [EMAIL PROTECTED] wrote: On Fri, 3 Oct 2008, Mitch Bradley wrote: ... since the XO hardware is fixed, why would you ship a kernel that used modules for any of the XO hardware? especially for anything that it needs at boot time? By and large, the required drivers are not modules. It's possible that we might have screwed up in some cases, but I think we've done the right thing for the most part. The built-in wireless device is on USB. but even USB drivers can be built-in, so there's no need to use any modules for anything that you will always have (possible exception, disabling the wireless for flying) if you don't need modules to boot, why do you need initrd? you should be able to just do everything from the main partition. Our activation security system is in an initrd so that the firmware can check its signature before booting it. The whole security thing adds a bunch of interesting wrinkles. ouch. try to make the initrd do as little as possible. neither of these require any changes to the Fedora stuff (I do this on every system that I run, have done so with many different distros, and never run into problems) remember that you can still have modules for USB devices, but not need to use any of them at boot time (if there are no USB devices plugged in) As mentioned, our wireless module is on an internal USB port. To what extent does that complicate the situation? it shouldn't. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Fri, 2008-10-03 at 11:32 -0700, [EMAIL PROTECTED] wrote: On Fri, 3 Oct 2008, Mitch Bradley wrote: [EMAIL PROTECTED] wrote: On Fri, 3 Oct 2008, Mitch Bradley wrote: if you don't need modules to boot, why do you need initrd? you should be able to just do everything from the main partition. Our activation security system is in an initrd so that the firmware can check its signature before booting it. The whole security thing adds a bunch of interesting wrinkles. ouch. try to make the initrd do as little as possible. The use of an initrd shouldn't have a substantial impact on boot time. There should not be a significant fundamental difference in how long it takes between booting into a userspace that happens to be from an initrd, does a little bit and then switchroots vs booting into a userspace off of a disk[1] Jeremy [1] With the one[2] obvious exception of whatever is done in the initrd takes time -- but if those things are moved later, they still take the same time. And if they're not needed, don't do them. [2] Also, there might be a tiny amount of time needed to uncompress the initrd and un-cpio, but that really should be nominal. If not, it means other problems later in the boot sequence ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Fri, 3 Oct 2008, Jeremy Katz wrote: On Fri, 2008-10-03 at 11:32 -0700, [EMAIL PROTECTED] wrote: On Fri, 3 Oct 2008, Mitch Bradley wrote: [EMAIL PROTECTED] wrote: On Fri, 3 Oct 2008, Mitch Bradley wrote: if you don't need modules to boot, why do you need initrd? you should be able to just do everything from the main partition. Our activation security system is in an initrd so that the firmware can check its signature before booting it. The whole security thing adds a bunch of interesting wrinkles. ouch. try to make the initrd do as little as possible. The use of an initrd shouldn't have a substantial impact on boot time. There should not be a significant fundamental difference in how long it takes between booting into a userspace that happens to be from an initrd, does a little bit and then switchroots vs booting into a userspace off of a disk[1] Jeremy [1] With the one[2] obvious exception of whatever is done in the initrd takes time -- but if those things are moved later, they still take the same time. And if they're not needed, don't do them. [2] Also, there might be a tiny amount of time needed to uncompress the initrd and un-cpio, but that really should be nominal. If not, it means other problems later in the boot sequence the default distro initrd images do a _lot_ of stuff that takes a significant amount of time, but since the OLPC initrd is doing completely different stuff it should not have the same problem, but that goes back to 'make it do as little as possible' David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Fri, 2008-10-03 at 11:49 -0700, [EMAIL PROTECTED] wrote: On Fri, 3 Oct 2008, Jeremy Katz wrote: [1] With the one[2] obvious exception of whatever is done in the initrd takes time -- but if those things are moved later, they still take the same time. And if they're not needed, don't do them. [2] Also, there might be a tiny amount of time needed to uncompress the initrd and un-cpio, but that really should be nominal. If not, it means other problems later in the boot sequence the default distro initrd images do a _lot_ of stuff that takes a significant amount of time, Yes, the distro initrds do a lot more than they used to. And do you know why -- because people *wanted* functionality and also because of functionality being moved out of the kernel into userspace. Trust me, at least some of the people maintaining initrd stuff would far rather have less code :-) but since the OLPC initrd is doing completely different stuff it should not have the same problem, but that goes back to 'make it do as little as possible' 'As little as possible' is still far from nothing and thus if initrds inherently introduce significant slow-downs just by being there, then that's very worth fixing rather than having kernel people bury their head in the sand. But I already had that argument with Arjan :-) Jeremy ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Fri, 3 Oct 2008, [EMAIL PROTECTED] wrote: On Fri, 3 Oct 2008, Jeremy Katz wrote: On Fri, 2008-10-03 at 11:32 -0700, [EMAIL PROTECTED] wrote: On Fri, 3 Oct 2008, Mitch Bradley wrote: [EMAIL PROTECTED] wrote: On Fri, 3 Oct 2008, Mitch Bradley wrote: if you don't need modules to boot, why do you need initrd? you should be able to just do everything from the main partition. Our activation security system is in an initrd so that the firmware can check its signature before booting it. The whole security thing adds a bunch of interesting wrinkles. ouch. try to make the initrd do as little as possible. The use of an initrd shouldn't have a substantial impact on boot time. There should not be a significant fundamental difference in how long it takes between booting into a userspace that happens to be from an initrd, does a little bit and then switchroots vs booting into a userspace off of a disk[1] Jeremy [1] With the one[2] obvious exception of whatever is done in the initrd takes time -- but if those things are moved later, they still take the same time. And if they're not needed, don't do them. [2] Also, there might be a tiny amount of time needed to uncompress the initrd and un-cpio, but that really should be nominal. If not, it means other problems later in the boot sequence the default distro initrd images do a _lot_ of stuff that takes a significant amount of time, but since the OLPC initrd is doing completely different stuff it should not have the same problem, but that goes back to 'make it do as little as possible' one other thing, Tivo has shown that you don't need to have an initrd to lock a device down, you just need some partiton somewhere that you can check. for that matter, if you were slightly crazy you could have the firmware check individual files on the filesystem, but keeping track of everything would be a mess. however, you _could_ do something where you store your init security stuff in a filesystem image on your real filesystem (accessed via a loop mount type of thing), similar code to what grub uses to find files on the system could find the security filesystem. this would be more complicated then a seperate partition, but has the advantage that you only loose the space that you need for the security stuff. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
