All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <rdunlap@xenotime.net>
To: Lasse Collin <lasse.collin@tukaani.org>
Cc: Jan Beulich <JBeulich@novell.com>, linux-kbuild@vger.kernel.org
Subject: Re: [PATCH] adjust XZ_DEC_* Kconfig defaults
Date: Wed, 9 Feb 2011 11:27:18 -0800	[thread overview]
Message-ID: <20110209112718.0622417f.rdunlap@xenotime.net> (raw)
In-Reply-To: <201102091151.08930.lasse.collin@tukaani.org>

On Wed, 9 Feb 2011 11:51:08 +0200 Lasse Collin wrote:

> On 2011-02-09 Jan Beulich wrote:
> > Having architecture specific decoders enabled by default makes little
> > sense - only at most one of the respective encoders is being used,
> > and hence the other decoders are not necessary in the common
> > (default) case.
> 
> It can be nice to be able to mount a Squashfs image containing ARM 
> binaries on a x86 desktop, but maybe that isn't important enough to keep 
> all BCJ filters enabled by default. If they are not enabled by default, 
> I think "if EXPERT" needs to be removed from those options too.
> 
> For bigger size savings, it doesn't seem too useful to have five 
> decompressors enabled by default (and behind "if EXPERT") for initramfs. 
> I added XZ to that list to be consistent with the existing methods, but 
> it wasn't the best thing to do.
> 
> Bzip2 and LZMA are completely __init, but most of the gzip, LZO, and XZ 
> code for initramfs is not __init. They pull zlib_inflate, 
> lzo_decompress, xz_dec, and crc32 modules into the kernel.
> 
> I think gzip and LZO support for initramfs should be enough by default, 
> because bzip2, LZMA, and XZ are slower to decompress. The compression 
> ratio of initramfs doesn't matter much on desktop systems so the fast 
> options are the best. Users of embedded systems will pick exactly one 
> method anyway, ignoring the defaults.

Hi,
Did you see this email?  what do you think of it?

https://lkml.org/lkml/2011/2/1/438
Subject: Change DECOMPRESS_LZMA to boolean

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

  reply	other threads:[~2011-02-09 19:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4D5260530200007800030F22@vpn.id2.novell.com>
2011-02-09  9:51 ` [PATCH] adjust XZ_DEC_* Kconfig defaults Lasse Collin
2011-02-09 19:27   ` Randy Dunlap [this message]
2011-02-09 20:18     ` Lasse Collin

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=20110209112718.0622417f.rdunlap@xenotime.net \
    --to=rdunlap@xenotime.net \
    --cc=JBeulich@novell.com \
    --cc=lasse.collin@tukaani.org \
    --cc=linux-kbuild@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.