5 sec boot

Mitch Bradley wmb at laptop.org
Sat Oct 4 22:54:06 EDT 2008


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
>
>   




More information about the Devel mailing list