Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Stefan Fröberg" <stefan.froberg@petroprogram.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 3/3] initramfs: add support for LZO and XZ compression methods
Date: Tue, 22 Jan 2013 20:17:55 +0200	[thread overview]
Message-ID: <50FED7D3.3060600@petroprogram.com> (raw)
In-Reply-To: <20130122180554.6c540102@skate>

22.1.2013 19:05, Thomas Petazzoni kirjoitti:
> Dear Gustavo Zacarias,
>
> On Mon, 21 Jan 2013 19:55:43 -0300, Gustavo Zacarias wrote:
>
>> +config BR2_TARGET_ROOTFS_CPIO_LZO
>> +	bool "lzo"
>> +	help
>> +	  Do compress the cpio filesystem with lzo.
>> +
>> +config BR2_TARGET_ROOTFS_CPIO_XZ
>> +	bool "xz"
>> +	help
>> +	  Do compress the cpio filesystem with xz.
> I don't remember exactly, but isn't the kernel build process itself
> capable of compressing the initramfs already? I remember we had some
> discussion about this a while ago, but I don't remember the outcome of
> these. Arnout was leading this discussion, IIRC.

If it's embedded initramfs then yes, kernel can handle it all itself
just nicely.
without needing to compress inside initramfs.
(images kernel.png and kernel2.png)

But if outside cpio-archive (aka initramfs) then no. It has to be done
by hand.
And like I said to Gustavo it's bad to do double compression.


Here's are the different combinations:

1 ) compressed initramfs  inside  compressed kernel = bad (waste of time
decompressing twice, and also waste of package file header size overhead)
2 ) compressed initramfs inside uncompressed kernel = better (no time
waste but still space waste)
3 ) uncompressed initramfs inside compressed kernel = best solution for
embedded initramfs (no time waste & time space waste)

4 ) uncompressed outside initramfs and uncompressed kernel (waste of
space and even according to some benchmarks, waste of time)
5 ) compressed outside initramfs and compressed kernel (no wasted time
and no wasted space)

So option 3 is best for embedded initramfs and option 5 for otherwise
for those who want more flexibility with their enivronment.
For example I could have this:

   
-------------------------------------------------------------------------------------------------------------------------------------------------
   |  embedded, uncompressed initramfs insize xz-compressed kernel, with
just busybox and minimal stuff |
  
--------------------------------------------------------------------------------------------------------------------------------------------------
                                                              |
  
---------------------------------------------------------------------------------------------------------------------------------
   | compressed outside initramfs with ncurses & directfb application,
like links web-browser    |
  
---------------------------------------------------------------------------------------------------------------------------------
                                                              |
 
----------------------------------------------------------------------------------------------------------------------------------
  | still another compressed initramfs with Xorg, firefox and all the
heavy stuff                             |
 
----------------------------------------------------------------------------------------------------------------------------------

All stackable one top over another (at least grub legacy allows giving
several initramfs).

And in Grub conf I could have boot entries like:
- Minimal system (just busybox and it's apps)
- Light system (ncurses, directfb and other non-Xorg "graphical" apps)
- Full system  (full Xorg stuff and apps)

Without outside initramfs option I would have to stick kernel (and it's
modules) to each of those initramfs files which would be a waste of space.
Now I have only one kernel (with or without initramfs) and 2 outside
initramfs which I can mix and match like lego blocks.

Stefan














> Best regards,
>
> Thomas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel.png
Type: image/png
Size: 24654 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130122/3fb45fea/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel2.png
Type: image/png
Size: 24921 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130122/3fb45fea/attachment-0003.png>

  reply	other threads:[~2013-01-22 18:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-21 22:55 [Buildroot] [PATCH 1/3] lzop: add LZOP definition for the host variant Gustavo Zacarias
2013-01-21 22:55 ` [Buildroot] [PATCH 2/3] xz: add XZ " Gustavo Zacarias
2013-01-21 22:55 ` [Buildroot] [PATCH 3/3] initramfs: add support for LZO and XZ compression methods Gustavo Zacarias
2013-01-21 23:38   ` Stefan Fröberg
2013-01-21 23:44     ` Gustavo Zacarias
2013-01-22  0:34       ` Stefan Fröberg
2013-01-22 17:05   ` Thomas Petazzoni
2013-01-22 18:17     ` Stefan Fröberg [this message]
2013-01-24  7:11       ` Arnout Vandecappelle
2013-01-24 11:55         ` Stefan Fröberg
2013-01-24 10:48       ` Gustavo Zacarias
2013-01-24 12:08         ` Stefan Fröberg
2013-01-24 12:13           ` Gustavo Zacarias
2013-01-24  7:09   ` Arnout Vandecappelle
2013-01-24 10:57     ` Gustavo Zacarias

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50FED7D3.3060600@petroprogram.com \
    --to=stefan.froberg@petroprogram.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox