s390/boot: improve install.sh script

Use proper quoting for the variables and explicitly distinguish between
command options and positional arguments.

Acked-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

kbuild: factor out the common installation code into scripts/install.sh

Many architectures have similar install.sh scripts.

The first half is really generic; it verifies that the kernel image
and System.map exist, then executes ~/bin/${INSTALLKERNEL} or
/sbin/${INSTALLKERNEL} if available.

The second half is kind of arch-specific; it copies the kernel image
and System.map to the destination, but the code is slightly different.

Factor out the generic part into scripts/install.sh.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

s390/arch: install kernels with their proper version ID

In case $INSTALLKERNEL is not available, we should install the kernel
image with its version number, and save the previous one accordingly.
Also, we're adding a hint so users know that they still need to
perform one more configuration step (usually adjusting zipl config).

Signed-off-by: Stefan Raspl <raspl@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

s390: Remove redundant license text

Now that the SPDX tag is in all arch/s390/ files, that identifies the
license in a specific and legally-defined manner. So the extra GPL text
wording in the remaining files can be removed as it is no longer needed
at all.

This is done on a quest to remove the 700+ different ways that files in
the kernel describe the GPL license text. And there's unneeded stuff
like the address (sometimes incorrect) for the FSF which is never
needed.

No copyright headers or other non-license-description text was removed.

Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

s390: add SPDX identifiers to the remaining files

It's good to have SPDX identifiers in all files to make it easier to
audit the kernel tree for correct licenses.

Update the remaining arch/s390/ files with the correct SPDX license
identifier based on the license text in the file itself. The SPDX
identifier is a legally binding shorthand, which can be used instead of
the full boiler plate text.

This work is based on a script and data from Thomas Gleixner, Philippe
Ombredanne, and Kate Stewart.

Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Cornelia Huck <cohuck@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Philippe Ombredanne <pombredanne@nexb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

kbuild: use INSTALLKERNEL to select customized installkernel script

Replace the use of CROSS_COMPILE to select a customized
installkernel script with the possibility to set INSTALLKERNEL
to select a custom installkernel script when running make:

make INSTALLKERNEL=arm-installkernel install

With this patch we are now more consistent across
different architectures - they did not all support use
of CROSS_COMPILE.

The use of CROSS_COMPILE was a hack as this really belongs
to gcc/binutils and the installkernel script does not change
just because we change toolchain.

The use of CROSS_COMPILE caused troubles with an upcoming patch
that saves CROSS_COMPILE when a kernel is built - it would no
longer be installable.
[Thanks to Peter Z. for this hint]

This patch undos what Ian did in commit:

0f8e2d62fa04441cd12c08ce521e84e5bd3f8a46
("use ${CROSS_COMPILE}installkernel in arch/*/boot/install.sh")

The patch has been lightly tested on x86 only - but all changes
looks obvious.

Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Mike Frysinger <vapier@gentoo.org> [blackfin]
Acked-by: Russell King <linux@arm.linux.org.uk> [arm]
Acked-by: Paul Mundt <lethal@linux-sh.org> [sh]
Acked-by: "H. Peter Anvin" <hpa@zytor.com> [x86]
Cc: Ian Campbell <icampbell@arcom.com>
Cc: Tony Luck <tony.luck@intel.com> [ia64]
Cc: Fenghua Yu <fenghua.yu@intel.com> [ia64]
Cc: Hirokazu Takata <takata@linux-m32r.org> [m32r]
Cc: Geert Uytterhoeven <geert@linux-m68k.org> [m68k]
Cc: Kyle McMartin <kyle@mcmartin.ca> [parisc]
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> [powerpc]
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> [s390]
Cc: Thomas Gleixner <tglx@linutronix.de> [x86]
Cc: Ingo Molnar <mingo@redhat.com> [x86]
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

[PATCH] use ${CROSS_COMPILE}installkernel in arch/*/boot/install.sh

The attached patch causes the various arch specific install.sh scripts to
look for ${CROSS_COMPILE}installkernel rather than just installkernel (in
both /sbin/ and ~/bin/ where the script already did this). This allows you
to have e.g. arm-linux-installkernel as a handy way to install on your
cross target. It also prevents the script picking up on the host
/sbin/installkernel which causes the script to fall through and do the
install itself (which is what I actually use myself, with $INSTALL_PATH
set).

I don't believe it causes back-compatibility problems since calling the
host installkernel was never likely to work or be what you wanted when
cross compiling anyway. If $CROSS_COMPILE isn't set then nothing changes.

I only use ARM and i386 myself but I figured it couldn't hurt to do the
whole lot. I've cc'd those who I hope are the arch maintainers for files
that I've touched.

Signed-off-by: Ian Campbell <icampbell@arcom.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Linux-2.6.12-rc2

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!