From: Rusty Russell <rusty@rustcorp.com.au>
To: Andreas Mohr <andi@lisas.de>, Andrew Morton <akpm@linux-foundation.org>
Cc: Bertrand Jacquin <beber@meleeweb.net>, Marco d'Itri <md@linux.it>,
linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
"Jon Masters" <jcm@redhat.com>
Subject: Re: [PATCH] modules: CONFIG_MODULE_COMPRESS: add hint that userspace support may easily be missing.
Date: Mon, 01 Jun 2015 15:56:44 +0930 [thread overview]
Message-ID: <87r3pwgd0b.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20150531152932.GA16337@rhlx01.hs-esslingen.de>
Andreas Mohr <andi@lisas.de> writes:
> Hi,
>
> I just had a not so nice experience
> when finally upgrading to a new 4.1-rc5
> with CONFIG_MODULE_COMPRESS newly enabled -
> userspace binary parts (kmod 18 or 20 in my case)
> did not have compression enabled
> (at least on Debian 8pre, vs. encountering it enabled on FC21)
> since it does not seem to be
> the default build configuration of kmod (yet?).
Sure. Let's get the maintainers to insert the actual version required
in the help text though.
Thanks,
Rusty.
> Doing a manual
> for gz in $(find . -name "*.gz"); do echo gunzip $gz; done
> depmod -a (somewhere temporarily in bootup scripts)
> manages to fix the grave problem
> introduced by erroneously having enabled CONFIG_MODULE_COMPRESS.
>
> Thus it seems that the Kconfig text was much more optimistic
> than a hapless user would want to encounter,
> thus I decided to have it updated.
>
>
> BTW: kmod and/or module-init-tools packages
> might want to provide a generic way to openly advertise
> certain build-configured "capabilities" in the binary -
> neither
> kmod --help
> nor
> kmod -V
> indicated whether or not they provided capabilities
> such as e.g. providing or not providing support of compression types
> and which ones.
> That would have been a very helpful way
> to reliably determine
> that support in fact is missing in the binary,
> rather than having to resort to clumsy hacks
> such as ldd or even strings.
>
>
> While this is a minor but useful addition
> rather than a severe fix,
> having a CC to stable@ added subsequently might be useful.
>
> Thanks!
>
> Signed-off-by: Andreas Mohr <andim2@users.sf.net>
>
> ---
> init/Kconfig | 18 +++++++++++++-----
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/init/Kconfig b/init/Kconfig
> index dc24dec..8e451f30 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1951,11 +1951,19 @@ config MODULE_COMPRESS
> This option compresses the kernel modules when 'make
> modules_install' is run.
>
> - The modules will be compressed either using gzip or xz depend on the
> - choice made in "Compression algorithm".
> -
> - module-init-tools has support for gzip format while kmod handle gzip
> - and xz compressed modules.
> + The module files will be compressed either using gzip or xz
> + depending on the choice made in "Compression algorithm".
> +
> + Obviously one will then need appropriate userspace parts
> + which are actually able to deal with compressed files, too:
> + module-init-tools has support for gzip format
> + while kmod handles gzip and xz compressed modules.
> + However, we observed that in several environments
> + module loader binaries do not have that enabled (yet?)
> + and thus bootup will fail fatally -
> + manually doing ldd on these binaries
> + to detect compression libraries
> + is a tell-tale sign of having support enabled.
>
> When a kernel module is installed from outside of the main kernel
> source and uses the Kbuild system for installing modules then that
> --
> 2.1.4
>
> --
> 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/
next prev parent reply other threads:[~2015-06-01 6:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-31 15:29 [PATCH] modules: CONFIG_MODULE_COMPRESS: add hint that userspace support may easily be missing Andreas Mohr
2015-06-01 6:26 ` Rusty Russell [this message]
2015-06-03 12:04 ` Michal Marek
2015-06-03 17:30 ` Lucas De Marchi
2015-06-03 17:36 ` Kay Sievers
2015-06-03 17:51 ` Lucas De Marchi
2015-06-04 1:30 ` Rusty Russell
2015-06-04 2:31 ` Lucas De Marchi
2015-06-04 19:53 ` Andreas Mohr
2015-06-04 20:22 ` Rusty Russell
2015-06-07 6:18 ` Lucas De Marchi
2015-06-04 2:51 ` Marco d'Itri
2015-06-04 3:19 ` Stephen Rothwell
2015-06-04 20:09 ` Andreas Mohr
2015-06-04 20:09 ` Andreas Mohr
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=87r3pwgd0b.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=akpm@linux-foundation.org \
--cc=andi@lisas.de \
--cc=beber@meleeweb.net \
--cc=jcm@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=md@linux.it \
/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.