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: NLinus Torvalds <torvalds@linux-foundation.org>

Use filechk to detect if the content changed or not.
Signed-off-by: NMichal Marek <mmarek@suse.cz>

This reverts commit d2aae847.

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: NLinus Torvalds <torvalds@linux-foundation.org>

Make modules_install fails with -j option:

   DEPMOD
 Usage: .../.source/linux/scripts/depmod.sh /sbin/depmod <kernelrelease>
 make[1]: *** [_modinst_post] Error 1

Adding kernelrelease dependency to fix this.
Signed-off-by: NRobert Richter <robert.richter@calxeda.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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: NMike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: NMichal 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: NArnd 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: NMichal Marek <mmarek@suse.cz>

The headers are now needed inside scripts/mod since 6543becf
("mod/file2alias: make modalias generation safe for cross compiling").
Reported-and-tested-by: NLad, Prabhakar <prabhakar.csengg@gmail.com>
Reported-and-tested-by: N"Jon Medhurst (Tixy)" <tixy@linaro.org>
Signed-off-by: NAndreas Schwab <schwab@linux-m68k.org>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

We need to hand down parallel build options like the internal make
--jobserver-fds one so that parallel builds can also happen when
building perf from the toplevel directory.

Make it so #1!
Signed-off-by: NBorislav Petkov <bp@suse.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/1361374353-30385-3-git-send-email-bp@alien8.deSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

We have CONFIG_SYMBOL_PREFIX, which three archs define to the string
"_".  But Al Viro broke this in "consolidate cond_syscall and
SYSCALL_ALIAS declarations" (in linux-next), and he's not the first to
do so.

Using CONFIG_SYMBOL_PREFIX is awkward, since we usually just want to
prefix it so something.  So various places define helpers which are
defined to nothing if CONFIG_SYMBOL_PREFIX isn't set:

1) include/asm-generic/unistd.h defines __SYMBOL_PREFIX.
2) include/asm-generic/vmlinux.lds.h defines VMLINUX_SYMBOL(sym)
3) include/linux/export.h defines MODULE_SYMBOL_PREFIX.
4) include/linux/kernel.h defines SYMBOL_PREFIX (which differs from #7)
5) kernel/modsign_certificate.S defines ASM_SYMBOL(sym)
6) scripts/modpost.c defines MODULE_SYMBOL_PREFIX
7) scripts/Makefile.lib defines SYMBOL_PREFIX on the commandline if
   CONFIG_SYMBOL_PREFIX is set, so that we have a non-string version
   for pasting.

(arch/h8300/include/asm/linkage.h defines SYMBOL_NAME(), too).

Let's solve this properly:
1) No more generic prefix, just CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX.
2) Make linux/export.h usable from asm.
3) Define VMLINUX_SYMBOL() and VMLINUX_SYMBOL_STR().
4) Make everyone use them.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Reviewed-by: NJames Hogan <james.hogan@imgtec.com>
Tested-by: James Hogan <james.hogan@imgtec.com> (metag)