<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/scripts, branch v3.2.47</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.2.47</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.2.47'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2012-10-17T02:49:34Z</updated>
<entry>
<title>kbuild: make: fix if_changed when command contains backslashes</title>
<updated>2012-10-17T02:49:34Z</updated>
<author>
<name>Sascha Hauer</name>
<email>s.hauer@pengutronix.de</email>
</author>
<published>2012-10-05T00:11:17Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=78333ac70289fc366841818359135402163e1927'/>
<id>urn:sha1:78333ac70289fc366841818359135402163e1927</id>
<content type='text'>
commit c353acba28fb3fa1fd05fd6b85a9fc7938330f9c upstream.

The call if_changed mechanism does not work when the command contains
backslashes.  This basically is an issue with lzo and bzip2 compressed
kernels.  The compressed binaries do not contain the uncompressed image
size, so these use size_append to append the size.  This results in
backslashes in the executed command.  With this if_changed always
detects a change in the command and rebuilds the compressed image even
if nothing has changed.

Fix this by escaping backslashes in make-cmd

Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Signed-off-by: Jan Luebbe &lt;jlu@pengutronix.de&gt;
Cc: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Cc: Bernhard Walle &lt;bernhard@bwalle.de&gt;
Cc: Michal Marek &lt;mmarek@suse.cz&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>kbuild: Fix gcc -x syntax</title>
<updated>2012-10-17T02:49:27Z</updated>
<author>
<name>Jean Delvare</name>
<email>jdelvare@suse.de</email>
</author>
<published>2012-10-02T14:42:36Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6454738d4395c8a79843f5c2e3eeb687f9b7e7a9'/>
<id>urn:sha1:6454738d4395c8a79843f5c2e3eeb687f9b7e7a9</id>
<content type='text'>
commit b1e0d8b70fa31821ebca3965f2ef8619d7c5e316 upstream.

The correct syntax for gcc -x is "gcc -x assembler", not
"gcc -xassembler". Even though the latter happens to work, the former
is what is documented in the manual page and thus what gcc wrappers
such as icecream do expect.

This isn't a cosmetic change. The missing space prevents icecream from
recognizing compilation tasks it can't handle, leading to silent kernel
miscompilations.

Besides me, credits go to Michael Matz and Dirk Mueller for
investigating the miscompilation issue and tracking it down to this
incorrect -x parameter syntax.

Signed-off-by: Jean Delvare &lt;jdelvare@suse.de&gt;
Acked-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Bernhard Walle &lt;bernhard@bwalle.de&gt;
Cc: Michal Marek &lt;mmarek@suse.cz&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Michal Marek &lt;mmarek@suse.cz&gt;
[bwh: Backported to 3.2: drop unneeded change to arch/x86/Makefile]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>scripts/Kbuild.include: Fix portability problem of "echo -e"</title>
<updated>2012-10-17T02:49:26Z</updated>
<author>
<name>Bernhard Walle</name>
<email>bernhard@bwalle.de</email>
</author>
<published>2012-02-26T17:35:18Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d3ccc5b382bf183ad55096743e4fa42d432b9885'/>
<id>urn:sha1:d3ccc5b382bf183ad55096743e4fa42d432b9885</id>
<content type='text'>
commit 875de98623fa2b29f0cb19915fe3292ab6daa1cb upstream.

"echo -e" is a GNU extension. When cross-compiling the kernel on a
BSD-like operating system (Mac OS X in my case), this doesn't work.

One could install a GNU version of echo, put that in the $PATH before
the system echo and use "/usr/bin/env echo", but the solution with
printf is simpler.

Since it is no disadvantage on Linux, I hope that gets accepted even if
cross-compiling the Linux kernel on another Unix operating system is
quite a rare use case.

Signed-off-by: Bernhard Walle &lt;bernhard@bwalle.de&gt;
Andreas Bießmann &lt;andreas@biessmann.de&gt;
Signed-off-by: Michal Marek &lt;mmarek@suse.cz&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>localmodconfig: Fix localyesconfig to set to 'y' not 'm'</title>
<updated>2012-10-17T02:49:20Z</updated>
<author>
<name>Yuta Ando</name>
<email>yuta.and@gmail.com</email>
</author>
<published>2012-10-01T14:24:30Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=5ed7d4de6853126fe9bb27d9cd443ee0a2d6e90a'/>
<id>urn:sha1:5ed7d4de6853126fe9bb27d9cd443ee0a2d6e90a</id>
<content type='text'>
commit 4eae518d4b01b0cbf2f0d8edb5a6f3d6245ee8fb upstream.

The kbuild target 'localyesconfig' has been same as 'localmodconfig'
since the commit 50bce3e "kconfig/streamline_config.pl: merge
local{mod,yes}config". The commit expects this script generates
different configure depending on target, but it was not yet implemented.

So I added code that sets to 'yes' when target is 'localyesconfig'.

Link: http://lkml.kernel.org/r/1349101470-12243-1-git-send-email-yuta.and@gmail.com

Cc: linux-kbuild@vger.kernel.org
Signed-off-by: Yuta Ando &lt;yuta.and@gmail.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@rostedt.homelinux.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>kbuild: Do not package /boot and /lib in make tar-pkg</title>
<updated>2012-10-17T02:49:09Z</updated>
<author>
<name>Michal Marek</name>
<email>mmarek@suse.cz</email>
</author>
<published>2012-09-25T14:03:03Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0767530346a06285e2c34b239976dae1d0d3d621'/>
<id>urn:sha1:0767530346a06285e2c34b239976dae1d0d3d621</id>
<content type='text'>
commit fe04ddf7c2910362f3817c8156e41cbd6c0ee35d upstream.

There were reports of users destroying their Fedora installs by a kernel
tarball that replaces the /lib -&gt; /usr/lib symlink. Let's remove the
toplevel directories from the tarball to prevent this from happening.

Reported-by: Andi Kleen &lt;andi@firstfloor.org&gt;
Suggested-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Michal Marek &lt;mmarek@suse.cz&gt;
[bwh: Fold in commit 3ce9e53e788881da0d5f3912f80e0dd6b501f304 to avoid
 conflicts]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>kbuild: do not check for ancient modutils tools</title>
<updated>2012-07-25T03:10:58Z</updated>
<author>
<name>Lucas De Marchi</name>
<email>lucas.demarchi@profusion.mobi</email>
</author>
<published>2012-01-17T16:50:51Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3838461c8d7479c84129c2744a3fab53e269e340'/>
<id>urn:sha1:3838461c8d7479c84129c2744a3fab53e269e340</id>
<content type='text'>
commit 620c231c7a7f48745094727bb612f6321cfc8844 upstream.

scripts/depmod.sh checks for the output of '-V' expecting that it has
module-init-tools in it. It's a hack to prevent users from using
modutils instead of module-init-tools, that only works with 2.4.x
kernels. This however prints an annoying warning for kmod tool, that is
currently replacing module-init-tools.

Rather than putting another check for kmod's version, just remove it
since users of 2.4.x kernel are unlikely to upgrade to 3.x, and if they
do, let depmod fail in that case because they should know what they are
doing.

Signed-off-by: Lucas De Marchi &lt;lucas.demarchi@profusion.mobi&gt;
Acked-by: WANG Cong &lt;amwang@redhat.com&gt;
Acked-By: Kay Sievers &lt;kay.sievers@vrfy.org&gt;
Signed-off-by: Michal Marek &lt;mmarek@suse.cz&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>x86, realmode: 16-bit real-mode code support for relocs tool</title>
<updated>2012-05-30T23:44:08Z</updated>
<author>
<name>H. Peter Anvin</name>
<email>hpa@linux.intel.com</email>
</author>
<published>2012-05-08T18:22:24Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b352fc61e3aaa363ab92560187ee994fb6a3e27d'/>
<id>urn:sha1:b352fc61e3aaa363ab92560187ee994fb6a3e27d</id>
<content type='text'>
commit 6520fe5564acf07ade7b18a1272db1184835c487 upstream.

A new option is added to the relocs tool called '--realmode'.
This option causes the generation of 16-bit segment relocations
and 32-bit linear relocations for the real-mode code. When
the real-mode code is moved to the low-memory during kernel
initialization, these relocation entries can be used to
relocate the code properly.

In the assembly code 16-bit segment relocations must be relative
to the 'real_mode_seg' absolute symbol. Linear relocations must be
relative to a symbol prefixed with 'pa_'.

16-bit segment relocation is used to load cs:ip in 16-bit code.
Linear relocations are used in the 32-bit code for relocatable
data references. They are declared in the linker script of the
real-mode code.

The relocs tool is moved to arch/x86/tools/relocs.c, and added new
target archscripts that can be used to build scripts needed building
an architecture.  be compiled before building the arch/x86 tree.

[ hpa: accelerating this because it detects invalid absolute
  relocations, a serious bug in binutils 2.22.52.0.x which currently
  produces bad kernels. ]

Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Link: http://lkml.kernel.org/r/1336501366-28617-2-git-send-email-jarkko.sakkinen@intel.com
Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@intel.com&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
[bwh: Backported to 3.2:
 - Adjust context (no archheaders; no insn_sanity)
 - Expand put_unaligned_le32()]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>Fix modpost failures in fedora 17</title>
<updated>2012-05-11T12:13:58Z</updated>
<author>
<name>David Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2012-04-26T00:41:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c2ea42542f001d57d32cf5c0300e31fb4af3f610'/>
<id>urn:sha1:c2ea42542f001d57d32cf5c0300e31fb4af3f610</id>
<content type='text'>
commit e88aa7bbbe3046a125ea1936b16bb921cc9c6349 upstream.

The symbol table on x86-64 starts to have entries that have names
like:

_GLOBAL__sub_I_65535_0___mod_x86cpu_device_table

They are of type STT_FUNCTION and this one had a length of 18.  This
matched the device ID validation logic and it barfed because the
length did not meet the device type's criteria.

--------------------
FATAL: arch/x86/crypto/aesni-intel: sizeof(struct x86cpu_device_id)=16 is not a modulo of the size of section __mod_x86cpu_device_table=18.
Fix definition of struct x86cpu_device_id in mod_devicetable.h
--------------------

These are some kind of compiler tool internal stuff being emitted and
not something we want to inspect in modpost's device ID table
validation code.

So skip the symbol if it is not of type STT_OBJECT.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Acked-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Signed-off-by: Michal Marek &lt;mmarek@suse.cz&gt;
Signed-off-by: Jonathan Nieder &lt;jrnieder@gmail.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>modpost: Fix modpost license checking of vmlinux.o</title>
<updated>2012-04-13T15:33:49Z</updated>
<author>
<name>Frank Rowand</name>
<email>frank.rowand@am.sony.com</email>
</author>
<published>2012-04-10T00:59:03Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=5fb8a151e767140e21da2cb83bf49be7755305f9'/>
<id>urn:sha1:5fb8a151e767140e21da2cb83bf49be7755305f9</id>
<content type='text'>
commit 258f742635360175564e9470eb060ff4d4b984e7 upstream.

Commit f02e8a6596b7 ("module: Sort exported symbols") sorts symbols
placing each of them in its own elf section.  This sorting and merging
into the canonical sections are done by the linker.

Unfortunately modpost to generate Module.symvers file parses vmlinux.o
(which is not linked yet) and all modules object files (which aren't
linked yet).  These aren't sanitized by the linker yet.  That breaks
modpost that can't detect license properly for modules.

This patch makes modpost aware of the new exported symbols structure.

[ This above is a slightly corrected version of the explanation of the
  problem, copied from commit 62a2635610db ("modpost: Fix modpost's
  license checking V3").  That commit fixed the problem for module
  object files, but not for vmlinux.o.  This patch fixes modpost for
  vmlinux.o. ]

Signed-off-by: Frank Rowand &lt;frank.rowand@am.sony.com&gt;
Signed-off-by: Alessio Igor Bogani &lt;abogani@kernel.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>modpost: fix ALL_INIT_DATA_SECTIONS</title>
<updated>2012-04-13T15:33:46Z</updated>
<author>
<name>Jan Beulich</name>
<email>JBeulich@suse.com</email>
</author>
<published>2012-03-08T09:41:25Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a465b08978d6b1109778101eeaccc150108624c7'/>
<id>urn:sha1:a465b08978d6b1109778101eeaccc150108624c7</id>
<content type='text'>
commit 9aaf440f8fabcebf9ea79a62ccf4c212e6544b49 upstream.

This was lacking a comma between two supposed to be separate strings.

Signed-off-by: Jan Beulich &lt;jbeulich@suse.com&gt;
Signed-off-by: Michal Marek &lt;mmarek@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
