[Buildroot] [PATCH] linux: Fix initramfs compression

[Valentine Barshak <gvaxon@gmail.com>]

On 10/08/2012 11:43 AM, Arnout Vandecappelle wrote:
> On 07/10/12 22:22, Valentine Barshak wrote:
>> The problem here is that we can't set initramfs compression mode
>> unless the initramfs source (CONFIG_INITRAMFS_SOURCE)
>> is set. We can only set RAM disk compression modes that should be
>> supported by the kernel (CONFIR_RD_...).
>>
>> The source is set by buildroot. So the user has no capability to
>> configure compression explicitly, unless he (she) sets
>> a fake initramfs source file, which will be overridden by buildroot.
>> IMHO, this is a bit hackish way to set anything
>> other than default, which is COMPRESSION_NONE.
>>
>> Yes, that is what most people want. I just didn't want to drop other
>> options in case somebody wants a compressed
>> initramfs image.
>> This could be needed for systems with low memory, for example.
>
>   True.  Still, I don't think that this corner case warrants the additional
> complexity of grepping etc. in the buildroot makefile.  Especially
> because it
> still doesn't give the user complete configuration freedom: if both GZIP
> and
> BZIP2 initrd compression options are enabled (like is the case in some
> of the
> kernel's defconfigs), then still GZIP will be chosen.

Right.

>
>   If we really want to support this in buildroot, then the choice should
> be added
> to fs/initramfs/Config.in.  But also here I doubt that the (maintenance)
> work of
> having this option is worth it, because it's likely that it will _never_
> be used.
>
>   As you say yourself, if you really do need the option, there is a
> possibility
> to do it.  And it's not as bad as you say, because when you run
> 'make linux-menuconfig', buildroot will first run a 'linux-configure' so
> the
> INITRAMFS_SOURCE will already be set.  (At least, I think so :-)

Indeed, so it's probably better to let the kernel config handle it, 
instead of attempting to force any compression mode in BR.

>
>
>   Regards,
>   Arnout
>
Thanks,
Val.