From: Valentine Barshak <gvaxon@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] initramfs compression and some other questions
Date: Fri, 05 Oct 2012 01:47:10 +0400 [thread overview]
Message-ID: <506E03DE.2020701@gmail.com> (raw)
In-Reply-To: <506C98F7.2000408@mind.be>
On 10/03/2012 11:58 PM, Arnout Vandecappelle wrote:
> On 03/10/12 19:54, Valentine Barshak wrote:
>> Hi,
>> I've been using buildroot for a small (i586) Linux recovery image,
>> having both the kernel and initramfs root in a single
>> image.
>>
>> By default, buildroot (linux/linux.mk) sets GZIP compression for
>> initramfs, and there's no option to choose other
>> compression mode.
>>
>> My question is why is GZIP compression forced for initramfs?
>> IMHO, initramfs compression doesn't make much sense, since
>> the kernel is compressed altogether with initramfs, and we
>> have double compression, that adds more size to the resulting image
>> and time overhead when unpacking.
>>
>> Why not remove the following lines from linux.mk?
>> $(call
>> KCONFIG_DISABLE_OPT,CONFIG_INITRAMFS_COMPRESSION_NONE,$(@D)/.config)
>> $(call
>> KCONFIG_ENABLE_OPT,CONFIG_INITRAMFS_COMPRESSION_GZIP,$(@D)/.config))
>>
>> Or probably use KCONFIG_ENABLE_OPT,CONFIG_INITRAMFS_COMPRESSION_NONE
>> instead?
>>
>> Besides, there are other compression methods supported by linux kernel,
>> so why force GZIP?
>
> Good idea. Care to make a patch?
I'll try to play with it a bit more and maybe eventually come up with a
patch.
>
>> BTW, I have submitted a number of patches to the list, that attempt
>> to fix some of the issues I've encountered while building my recovery
>> image. Is it the right place to share patches or
>> do I need to use bugz and file a bug for each change?
>
> It's the right place. We don't use bugzilla that much - basically
> only for
> bugs that aren't resolved (yet).
>
>
>> I have some more changes that I'd like to share.
>> It's been no ack/nack for the stuff I sent last week. So I'm kind of
>> wondering whether this stuff is needed upstream.
>
> It just takes a while before patches get committed. As long as you react
> to the comments you get (like you did), they should be included in the long
> run. But it can take months...
>
Really hope it's gonna be faster than that. It's hard to keep track of
things for months.
BTW, some of the patches have got in already, thanks to Peter.
>
>> And the last question is about adding new packages to buildroot.
>> For example, do you plan to add a pdf viewer?
>>
>> I've added epdfview, it seems to work fine. Is there any reason
>> to not include it in the mainstream buildroot?
>>
>> I've also added tigervnc for my small recovery image.
>> Seems to work fine as well.
>> Do you plan to include it as well or is it considered unneeded for the
>> majority of the buildroot users?
>
> Well, firefox is on the way in, so a pdf viewer shouldn't be a problem
> :-)
hehe, OK, I'll prolly prepare some more patches if I have time.
Thanks Arnout.
>
> Regards,
> Arnout
>
Regards,
Val.
prev parent reply other threads:[~2012-10-04 21:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-03 17:54 [Buildroot] initramfs compression and some other questions Valentine Barshak
2012-10-03 19:58 ` Arnout Vandecappelle
2012-10-04 21:47 ` Valentine Barshak [this message]
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=506E03DE.2020701@gmail.com \
--to=gvaxon@gmail.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