Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752888AbbFDUJb (ORCPT ); Thu, 4 Jun 2015 16:09:31 -0400 Received: from rhlx01.hs-esslingen.de ([129.143.116.10]:58355 "EHLO rhlx01.hs-esslingen.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752230AbbFDUJ2 convert rfc822-to-8bit (ORCPT ); Thu, 4 Jun 2015 16:09:28 -0400 Date: Thu, 4 Jun 2015 22:09:27 +0200 From: Andreas Mohr To: Stephen Rothwell Cc: Rusty Russell , Lucas De Marchi , Andreas Mohr , Andrew Morton , Bertrand Jacquin , "Marco d'Itri" , linux-modules , lkml , Jon Masters Subject: Re: [PATCH] modules: CONFIG_MODULE_COMPRESS: add hint that userspace support may easily be missing. Message-ID: <20150604200927.GB15890@rhlx01.hs-esslingen.de> References: <20150531152932.GA16337@rhlx01.hs-esslingen.de> <87r3pwgd0b.fsf@rustcorp.com.au> <87h9qouuny.fsf@rustcorp.com.au> <20150604131946.6441b568@canb.auug.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8BIT In-Reply-To: <20150604131946.6441b568@canb.auug.org.au> X-Priority: none User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2417 Lines: 65 Hi, On Thu, Jun 04, 2015 at 01:19:46PM +1000, Stephen Rothwell wrote: > Hi Rusty, > > But disappointing that Debian doesn't configure with it, and there's no > > easy way to check it. Looks like Ubuntu vivid is the same. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772628 Crap, that URL now is an implicit strong suggestion that I didn't do my homework ;) (it already described large parts prior to me regurgitating this issue due to being unaware of this history here). Thanks to R.Russell for a very nice shortening and extension of the help text! Since the issue of .gz vs. .xz redundancy came up (with people "threatening" to support only one alternative), I want to mention that when having to choose one I'd tend to activating the .xz library dependency: - while it has higher compression demands, hardware is getting beefier all the time, thus it should not matter (especially vs. the dominantly many decompression runs) - it's simply the "more modern" and future-proof option, thus it should be favoured slightly since the system as a whole would want to make reasonably quick development/evolution "forward progress" rather than sticking to less favourable mechanisms - .xz has been available for some time already i.e. the time window of "distro support maturity" is a given [a counter-point might be that module-init-tools supports .gz only, but then modern binary setups which chose .xz would already have been shipped with kmod only] OK, having said that, I'm unsure what to think of the Debian package's decision to not support compression so far (and that even in times where kmod does not provide a runtime option yet to query the actual set of support flags). >From a library dependency POV it may be attractive to skip compression, and since Debian usually has a fixed setup where non-compressed files are a given, this seems like a valid choice. It's just that for e.g. these situations: - people with many custom kernels installed - space-constrained systems this is quite a nuisance that is a wee bit too unexpected (/show-stopper) - took me roughly > 30 minutes to get it researched / resolved. Thanks, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/