lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 11 Apr 2014 14:03:27 +0200 From: Paul Bolle <pebolle@...cali.nl> To: Michael Fyles <mf@...ston.net> Cc: "Prasad J. Pandit" <ppandit@...hat.com>, linux-kernel@...r.kernel.org Subject: Re: [PATCH] initramfs: remove "compression mode" choice 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists