| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since module-init-tools (gzip) and kmod (gzip and xz) support compressed
modules, it could be useful to include a support for compressing modules
right after having them installed. Doing this in kbuild instead of per
distro can permit to make this kind of usage more generic.
This patch add a Kconfig entry to "Enable loadable module support" menu
and let you choose to compress using gzip (default) or xz.
Both gzip and xz does not used any extra -[1-9] option since Andi Kleen
and Rusty Russell prove no gain is made using them. gzip is called with -n
argument to avoid storing original filename inside compressed file, that
way we can save some more bytes.
On a v3.16 kernel, 'make allmodconfig' generated 4680 modules for a
total of 378MB (no strip, no sign, no compress), the following table
shows observed disk space gain based on the allmodconfig .config :
| time |
+-------------+-----------------+
| manual .ko | make | size | percent
| compression | modules_install | | gain
+-------------+-----------------+------+--------
- | | 18.61s | 378M |
GZIP | 3m16s | 3m37s | 102M | 73.41%
XZ | 5m22s | 5m39s | 77M | 79.83%
The gain for restricted environnement seems to be interesting while
uncompress can be time consuming but happens only while loading a module,
that is generally done only once.
This is fully compatible with signed modules while the signed module is
compressed. module-init-tools or kmod handles decompression
and provide to other layer the uncompressed but signed payload.
Reviewed-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Bertrand Jacquin <beber@meleeweb.net>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
|
| |
|
|
|
|
|
|
|
| |
Note: shouldn't we use 'install -D $(2)/$@ $@' instead of mkdir
and cp ?
Reviewed-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Bertrand Jacquin <beber@meleeweb.net>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
|
| |
|
|
|
| |
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
| |
|
|
|
|
|
|
|
| |
The script still spits out an error ("Can't read private key") but we
don't break modules_install.
Reported-by: Bruno Wolff III <bruno@wolff.to>
Original-patch-by: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Linus deleted the old code and put signing on the install command,
I fixed it to extract the keyid and signer-name within sign-file
and cleaned up that script now it always signs in-place.
Some enthusiast should convert sign-key to perl and pull
x509keyid into it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This error may happen when the user's id or path includes .ko string.
For example, user's id is xxx.ko and building test.ko module,
the test.mod file lists ko name and all object files.
/home/xxx.ko/kernel_dev/device/drivers/test.ko
/home/xxx.ko/kernel_dev/device/drivers/test_main.o
/home/xxx.ko/kernel_dev/device/drivers/test_io.o ...
Current Makefile.modpost and Makefile.modinst find and list up not
only test.ko but also other object files.
because all of object file's path includes .ko string.
This is a patch to fix it.
Signed-off-by: Gunho Lee <gunho.lee@lge.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit ad7a953c522ceb496611d127e51e278bfe0ff483.
And commit: ("allow stripping of generated symbols under CONFIG_KALLSYMS_ALL")
9bb482476c6c9d1ae033306440c51ceac93ea80c
These stripping patches has caused a set of issues:
1) People have reported compatibility issues with binutils due to
lack of support for `--strip-unneeded-symbols' with objcopy 2.15.92.0.2
Reported by: Wenji
2) ccache and distcc no longer works as expeced
Reported by: Ted, Roland, + others
3) The installed modules increased a lot in size
Reported by: Ted, Davej + others
Reported-by: Wenji Huang <wenji.huang@oracle.com>
Reported-by: "Theodore Ts'o" <tytso@mit.edu>
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch changes the way __crc_ symbols are being resolved from
using ld to do so to using the assembler, thus allowing these symbols
to be marked local (the linker creates then as global ones) and hence
allow stripping (for modules) or ignoring (for vmlinux) them. While at
this, also strip other generated symbols during module installation.
One potentially debatable point is the handling of the flags passeed
to gcc when translating the intermediate assembly file into an object:
passing $(c_flags) unchanged doesn't work as gcc passes --gdwarf2 to
gas whenever is sees any -g* option, even for -g0, and despite the
fact that the compiler would have already produced all necessary debug
info in the C->assembly translation phase. I took the approach of just
filtering out all -g* options, but an alternative to such negative
filtering might be to have a positive filter which might, in the ideal
case allow just all the -Wa,* options to pass through.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Eric Sandeen <sandeen@redhat.com> reported:
Installing external modules is supposed to put them in some path
under /lib/modules/<version>/extra/subdir/, but this change:
http://linux.bkbits.net:8080/linux-2.6/?PAGE=cset&REV=1.1982.9.23
makes them go under /lib/modules/<version>/extrasubdir
(for example, make M=fs/ext3 modules_install puts ext3.ko in
/lib/modules/<version>/extrafs/ext3.ko)
This was the case only when specifying a trailing slash to M=..
Fixed by removing trailing slash if present so
we correctly match dir part of target.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Eric Sandeen <sandeen@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add option for stripping modules while installing them.
This function adds support for stripping modules while they are being
installed. CONFIG_DEBUG_KERNEL (which will probably become more
popular as developers use kdump) causes the size of the installed
modules to grow by a factor of 9 or so.
Some kernel package systems solve this problem by stripping the debug
information from /lib/modules after running "make modules_install",
but that may not work for people who are installing directly into
/lib/modules --- root partitions that were sized to handle 16 megs
worth of modules may not be quite so happy with 145 megs of modules,
so the "make modules_install" never succeeds.
This patch allows such users to request modules_install to strip the
modules as they are installed.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The kbuild system takes advantage of an incorrect behavior in GNU make.
Once this behavior is fixed, all files in the kernel rebuild every time,
even if nothing has changed. This patch ensures kbuild works with both
the incorrect and correct behaviors of GNU make.
For more details on the incorrect behavior, see:
http://lists.gnu.org/archive/html/bug-make/2006-03/msg00003.html
Changes in this patch:
- Keep all targets that are to be marked .PHONY in a variable, PHONY.
- Add .PHONY: $(PHONY) to mark them properly.
- Remove any $(PHONY) files from the $? list when determining whether
targets are up-to-date or not.
Signed-off-by: Paul Smith <psmith@gnu.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
| |
|
|
|
|
|
|
|
|
| |
Kbuild.include is a placeholder for definitions originally present in
both the top-level Makefile and scripts/Makefile.build.
There were a slight difference in the filechk definition, so the most videly
used version was kept and usr/Makefile was adopted for this syntax.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
---
|
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|
