linux-kernel - Re: [PATCH] Compress kernel modules on installation.

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 26 Dec 2008 23:57:48 +0100
From:	Sam Ravnborg <sam@...nborg.org>
To:	Jan Engelhardt <jengelh@...ozas.de>
Cc:	Steve Brokenshire <sbrokenshire@...tia.co.uk>,
	linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org
Subject: Re: [PATCH] Compress kernel modules on installation.

On Fri, Dec 26, 2008 at 08:50:34PM +0100, Jan Engelhardt wrote:
> 
> On Friday 2008-12-26 20:48, Sam Ravnborg wrote:
> >> >> 
> >> >> This patch allows kernel modules to be compressed when 'make
> >> >> modules_install' is run after being copied to
> >> >> the /lib/module/<version>/<...> directory which is useful if you have
> >> >> module-init-tools installed with --enable-zlib. This patch adds an
> >> >> option (MODULE_COMPRESS) to the kernel configuration file (specifically
> >> >> init/Kconfig) so that the kernel modules will compressed if
> >> >> MODULE_COMPRESS is set.
> >> 
> >> I recently started compressing my kernel modules and that saved me
> >> at least 70 MB of disk space on mostlyallmodconfig.
> >> (And no, the argument of disks being cheap is not so true with
> >> CF or SSD.)
> >> Distro is lazy and wants to wait for upstream to have it,
> >> so is there any chance of getting this proposal in?
> >
> >Steve said he wanted to try to make the solution more
> >scalable so I am awaiting a new patch.
> 
> Hm, all I needed was this patch. It might fire up some people,
> but it's got all the scalability I could think of..

Jan - there is obviously no way I could apply this patch
so late in the cycle. 
The original patch that made this a CONFIG option is
then much better as we avoid forcing new and untested
behaviour on the users.

We all know that compressing the modules are simple.
And unless someone comes up with *very* good arguments
then we should just use gzip with default parameters.

If we go for the "keep the .ko extension but compress"
then someone needs to answer the obvious questions:
- will this break on a typical distribution
- will this break busybox users

	Sam
--
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/