Commit 1bf49dd4be ("./Makefile: export initial ramdisk compression
config option") started setting the INITRD_COMPRESS environment variable
depending on which decompression models the kernel had available.
That is completely broken.
For example, we by default have CONFIG_RD_LZ4 enabled, and are able to
decompress such an initrd, but the user tools to *create* such an initrd
may not be availble. So trying to tell dracut to generate an
lz4-compressed image just because we can decode such an image is
completely inappropriate.
Cc: J P <ppandit@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
According to Documentation/Changes, make 3.80 is still being supported
for building the kernel, hence make files must not make (unconditional)
use of features introduced only in newer versions.
Commit 1bf49dd4be ("./Makefile: export initial ramdisk compression
config option") however introduced "else ifeq" constructs which make
3.80 doesn't understand. Replace the logic there with more conventional
(in the kernel build infrastructure) list constructs (except that the
list here is intentionally limited to exactly one element).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: P J P <ppandit@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Make menuconfig allows one to choose compression format of an initial
ramdisk image. But this choice does not result in duly compressed ramdisk
image. Because - $ make install - does not pass on the selected
compression choice to the dracut(8) tool, which creates the initramfs
file. dracut(8) generates the image with the default compression, ie.
gzip(1).
This patch exports the selected compression option to a sub-shell
environment, so that it could be used by dracut(8) tool to generate
appropriately compressed initramfs images.
There isn't a straightforward way to pass on options to dracut(8) via
positional parameters. Because it is indirectly invoked at the end of a $
make install sequence.
# make install
-> arch/$arch/boot/Makefile
-> arch/$arch/boot/install.sh
-> /sbing/installkernel ...
-> /sbin/new-kernel-pkg ...
-> /sbin/dracut ...
Signed-off-by: P J P <ppandit@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When building the kernel in a shell which defines GREP_OPTIONS so that
grep behavior is modified, we can break the generation of the syscalls
table like so:
__SYSCALL_COMMON(^[[01;31m^[[K0^[[m^[[K, sys_read, sys_read)
__SYSCALL_COMMON(^[[01;31m^[[K1^[[m^[[K, sys_write, sys_write)
__SYSCALL_COMMON(^[[01;31m^[[K1^[[m^[[K0, sys_mprotect, sys_mprotect) ...
This is just the initial breakage, later we barf when generating
modules.
In this case, GREP_OPTIONS contains "--color=always" which adds the shell
colors markup and completely fudges the headers under ...generated/asm/.
Fix that by unexporting the GREP_OPTIONS variable for the whole kernel
build as we tend to use grep at a bunch of places.
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Michal Marek <mmarek@suse.cz>
The common error found in forward-ported/backported patches is missing
headers. One recent example (files and function names are mangled):
void foo(){}
EXPORT_SYMBOL(foo);
gave only warning
foo.c:12345678:5: warning: function declaration isn't a prototype [-Wstrict-prototypes]
void foo(){}
^
foo.c:12345679:5: warning: data definition has no type or storage class [enabled by default]
EXPORT_SYMBOL(foo);
foo.c:12345679:5: warning: type defaults to 'int' in declaration of 'EXORT_SYMBOL' [-Werror=implicit-int]
Now it's a fatal error. Tested on x86_64 allyesconfig.
[akpm@linux-foundation.org: fix typos in comments]
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
This reverts the Linux for Workgroups thing. And no, before somebody
asks, we're not doing Linux95. Not for a few years, at least.
Sure, the flag added some color to the logo, and could have remained as
a testament to my leet gimp skills. But no. And I'll do this early, to
avoid the chance of forgetting when I'm doing the actual rc1 release on
the road.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit d2aae8477c.
It is completely and utterly broken. Module install should not build
any files, and adding broken dependencies to "help" it build files is
complete and utter sh*t.
The kernel should not be built by root, and "make install" and "make
module_install" (that for obvious reasons need to be run as root)
absolutely must not build any files. They should only ever copy the
already-built files over.
So having dependencies for the install targets is wrong, wrong, wrong.
If you try to install a kernel without building it first, you *should*
get errors. The build system shouldn't try to help root build the files.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The following issue can be reproduced with Linus' tree on
an x86_64 server.
>+ cp /home/user/rpmbuild-test/BUILDROOT/kernel-3.9.2.x86_64/boot/vmlinuz-3.9.2
>cp: missing destination file operand after
>/home/user/rpmbuild-test/BUILDROOT/kernel-3.9.2-1.x86_64/boot/vmlinuz-3.9.2'
>Try `cp --help' for more information.
>error: Bad exit status from /var/tmp/rpm-tmp.R4o0iI (%install)
Here are the commands to reproduce:
make defconfig
make rpm-pkg
Use the resulting src rpm to build as follows:
mkdir ~/rpmbuild-test
cd ~/rpmbuild-test
rpmbuild --rebuild --define "_topdir `pwd`" -vv ~/rpmbuild/SRPMS/kernel-3.10.0_rc1+-1.src.rpm
The issue is because the %install script uses $KBUILD_IMAGE and it hasn't
been set since it is only available in the kbuild system and not in the
%install script.
This patch adds a Makefile target to emit the image_name that can be used
and modifies the mkspec to use the dynamic name in %install.
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
gcc-4.7 and higher add a lot of false positive warnings about
potential uses of uninitialized warnings, but only when optimizing
for size (-Os). This is the default when building allyesconfig,
which turns on CONFIG_CC_OPTIMIZE_FOR_SIZE.
In order to avoid getting a lot of patches that initialize such
variables and accidentally hide real errors along the way, let's
just turn off this warning on the respective gcc versions
when building with size optimizations. The -Wmaybe-uninitialized
option was introduced in the same gcc version (4.7) that is now
causing the false positives, so there is no effect on older compilers.
A side effect is that when building with CONFIG_CC_OPTIMIZE_FOR_SIZE,
we might now see /fewer/ warnings about possibly uninitialized
warnings than with -O2, but that is still much better than seeing
warnings known to be bogus.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The source tree can contain lots of uninteresting data like tag or
cscope files, packaging which slows down make rpm needlessly. It can
also break the build, if the tree contains an unrelated file named
*.spec. The downside of this change is that new subdirectories have to
be added to the KBUILD_ALLDIRS variable in the top-level Makefile. The
upside is that the behavior is more predictable.
Signed-off-by: Michal Marek <mmarek@suse.cz>
The headers are now needed inside scripts/mod since 6543bec
("mod/file2alias: make modalias generation safe for cross compiling").
Reported-and-tested-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Reported-and-tested-by: "Jon Medhurst (Tixy)" <tixy@linaro.org>
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Linus Torvalds