initramfs: remove "compression mode" choice

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.

---
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(-)

index 642f503d3e9f..2d4c77eecf2e 100644
@@ -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

Not in mainline or linux-next.

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

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

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