All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Fyles <mf@vorston.net>
To: Paul Bolle <pebolle@tiscali.nl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] initramfs: remove "compression mode" choice
Date: Fri, 11 Apr 2014 12:26:11 +0100	[thread overview]
Message-ID: <20140411112611.GA508@dev0.mafconsulting.com> (raw)
In-Reply-To: <1396958857.26620.35.camel@x220>

On 2014-04-08 14:07:37+0200, Paul Bolle wrote:
> Commit 9ba4bcb64589 ("initramfs: read CONFIG_RD_ variables for
> initramfs compression") removed the users of the various
> INITRAMFS_COMPRESSION_* Kconfig symbols. So since v3.13 the entire
> "Built-in initramfs compression mode" choice is a set of knobs connected
> to nothing. The entire choice can safely be removed.

Whilst I agree (for my use-cases) with INITRAMFS_COMPRESSION and
RD being merged, I think it has happened the wrong way round.

Commit 9ba4bcb64589 mistakenly forced the logic in usr/Makefile
to prioritise the selection of RD options such that selecting
more than one supported compression pretty much rail-roads you
into having your initrd compressed with gzip. This happends
because because suffix-y gets updated once for each supported
compression and, by default (on x86, at least) all compressions
are supported.

I think that either:
1. the options should be merged (with whatever name gets chosen)
   and pick both the run-time supported and the build-time
   compressions
2. both options should remain, with one choosing the supported
   run-time compressions and the other choosing the build-time
   compression

If 1 is chosen, it would be advantageous to have RD as a
mutually-exclusive choice -- this would be the place to put all
the help texts that your patch removes.

I currently have a patch that performs 2, if you decide that
might be better.

-- 
Michael Fyles

  parent reply	other threads:[~2014-04-11 11:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-08 12:07 [PATCH] initramfs: remove "compression mode" choice Paul Bolle
2014-04-08 13:29 ` P J P
2014-04-08 14:32   ` Paul Bolle
2014-04-08 14:46     ` P J P
2014-04-11 11:26 ` Michael Fyles [this message]
2014-04-11 12:03   ` Paul Bolle
2014-04-11 12:55     ` P J P

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=20140411112611.GA508@dev0.mafconsulting.com \
    --to=mf@vorston.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pebolle@tiscali.nl \
    /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.