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.
Signed-off-by: Paul Bolle <[email protected]>
---
The help texts that are removed here contain a bit of information, eg on
the various compression algorithms. Is it useful enough to be readded
somewhere else?
"P J P" apparently has two redhat.com addresses.
usr/Kconfig | 77 -------------------------------------------------------------
1 file changed, 77 deletions(-)
diff --git a/usr/Kconfig b/usr/Kconfig
index 642f503d3e9f..2d4c77eecf2e 100644
--- a/usr/Kconfig
+++ b/usr/Kconfig
@@ -98,80 +98,3 @@ config RD_LZ4
help
Support loading of a LZ4 encoded initial ramdisk or cpio buffer
If unsure, say N.
-
-choice
- prompt "Built-in initramfs compression mode" if INITRAMFS_SOURCE!=""
- help
- This option decides by which algorithm the builtin initramfs
- will be compressed. Several compression algorithms are
- available, which differ in efficiency, compression and
- decompression speed. Compression speed is only relevant
- when building a kernel. Decompression speed is relevant at
- each boot.
-
- If you have any problems with bzip2 or LZMA compressed
- initramfs, mail me (Alain Knaff) <[email protected]>.
-
- High compression options are mostly useful for users who are
- low on RAM, since it reduces the memory consumption during
- boot.
-
- If in doubt, select 'gzip'
-
-config INITRAMFS_COMPRESSION_NONE
- bool "None"
- help
- Do not compress the built-in initramfs at all. This may
- sound wasteful in space, but, you should be aware that the
- built-in initramfs will be compressed at a later stage
- anyways along with the rest of the kernel, on those
- architectures that support this.
- However, not compressing the initramfs may lead to slightly
- higher memory consumption during a short time at boot, while
- both the cpio image and the unpacked filesystem image will
- be present in memory simultaneously
-
-config INITRAMFS_COMPRESSION_GZIP
- bool "Gzip"
- depends on RD_GZIP
- help
- The old and tried gzip compression. It provides a good balance
- between compression ratio and decompression speed.
-
-config INITRAMFS_COMPRESSION_BZIP2
- bool "Bzip2"
- depends on RD_BZIP2
- help
- Its compression ratio and speed is intermediate.
- Decompression speed is slowest among the choices. The initramfs
- size is about 10% smaller with bzip2, in comparison to gzip.
- Bzip2 uses a large amount of memory. For modern kernels you
- will need at least 8MB RAM or more for booting.
-
-config INITRAMFS_COMPRESSION_LZMA
- bool "LZMA"
- depends on RD_LZMA
- help
- This algorithm's compression ratio is best.
- Decompression speed is between the other choices.
- Compression is slowest. The initramfs size is about 33%
- smaller with LZMA in comparison to gzip.
-
-config INITRAMFS_COMPRESSION_XZ
- bool "XZ"
- depends on RD_XZ
- help
- XZ uses the LZMA2 algorithm. The initramfs size is about 30%
- smaller with XZ in comparison to gzip. Decompression speed
- is better than that of bzip2 but worse than gzip and LZO.
- Compression is slow.
-
-config INITRAMFS_COMPRESSION_LZO
- bool "LZO"
- depends on RD_LZO
- help
- Its compression ratio is the poorest among the choices. The kernel
- size is about 10% bigger than gzip; however its speed
- (both compression and decompression) is the fastest.
-
-endchoice
--
1.9.0
Hello Paul,
+-- On Tue, 8 Apr 2014, Paul Bolle wrote --+
| "Built-in initramfs compression mode" choice is a set of knobs connected
| to nothing. The entire choice can safely be removed.
This patch has already been submitted upstream; though not sure if it is
merged yet.
Please see -> https://lkml.org/lkml/2013/11/25/21
@Andrew: is it queued to be merged upstream?
Thank you.
--
- P J P
On Tue, 2014-04-08 at 18:59 +0530, P J P wrote:
> +-- On Tue, 8 Apr 2014, Paul Bolle wrote --+
> | "Built-in initramfs compression mode" choice is a set of knobs connected
> | to nothing. The entire choice can safely be removed.
> This patch has already been submitted upstream; though not sure if it is
> merged yet.
Not in mainline or linux-next.
> Please see -> https://lkml.org/lkml/2013/11/25/21
>
> @Andrew: is it queued to be merged upstream?
lkml.org shows nothing for me, currently, but I think it's the same one as
http://marc.info/?l=linux-kernel&m=138536209816822&w=2 . Though I think
the commit explanation of my patch is clearer I'm fine with Hristo's
patch. And that patch also predates mine by five months.
Thanks,
Paul Bolle
+-- On Tue, 8 Apr 2014, Paul Bolle wrote --+
| lkml.org shows nothing for me, currently, but I think it's the same one as
| http://marc.info/?l=linux-kernel&m=138536209816822&w=2 .
Yes, that's the one.
--
- P J P
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
On Fri, 2014-04-11 at 12:26 +0100, Michael Fyles wrote:
> 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.
This patch is a straightforward cleanup. It can't possibly change
anything for anyone.
My local .config tracks what Fedora uses for their kernel builds. I
don't think Fedora ever set one of the INITRAMFS_COMPRESSION_* options.
I didn't even knew these options became unused before grepping tree for
something entirely different.
But, of course, it's possible that 9ba4bcb64589 ("initramfs: read
CONFIG_RD_ variables for initramfs compression") broke stuff. If so,
that should probably be fixed. But you're likely better off discussing
that with Prasad (added as Cc).
Paul Bolle
Hello Michael,
+-- On Fri, 11 Apr 2014, Paul Bolle wrote --+
| On Fri, 2014-04-11 at 12:26 +0100, Michael Fyles wrote:
| > 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.
IIUC, that's not because of the commit. Even earlier it was the same.
Because that's how Makefile reads and updates the variables. Now that .gzip is
listed last in the make file, it defaults to .gzip when all options are set.
Otherwise it would default to .lz4 or .lzo before lz4 was introduced.
See -> https://lkml.org/lkml/2013/12/23/170
| > 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.
I don't get it. You mean one option for build time compression and another
for run time compression? Shouldn't those two be exactly same?
--
- P J P