dect
/
linux-2.6
Archived
13
0
Fork 0
Commit Graph

4 Commits

Author SHA1 Message Date
Brian Gerst 352dd1df32 gitignore: misc files
Ignore all files generated from *_shipped files, plus a few others.

Signed-off-by: Brian Gerst <bgerst@didntduck.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2006-01-01 22:21:50 +01:00
Sam Ravnborg c40f56409d kbuild: Create _shipped files for genksyms
Generate _shipped files so the genksyms change in previous commit is enabled.
The files are generated with latest versions of the tools:

bison (GNU Bison) 2.0
flex version 2.5.4
GNU gperf 3.0.1

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2005-12-26 22:53:25 +01:00
Robin Holt a89a0a2354 kbuild: Fix genksyms handling of DEFINE_PER_CPU(struct foo_s *, bar);
This is a one-line change to parse.y.
To take advantage of this the scripts/genksyms/*_shipped files needs to
be rebuild - this is the next patch.

When a .c file contains:
DEFINE_PER_CPU(struct foo_s *, bar);

the .cpp output looks like:
__attribute__((__section__(".data.percpu"))) __typeof__(struct foo_s *) per_cpu__bar;

With the existing parse.y, the value inside the paranthesis of
__typeof__() does not evaluate as a type_specifier and therefore
per_cpu__bar does not get assigned a type for genksyms which results in
the EXPORT_PER_CPU_SYMBOL() not generating a CRC value.

I have compared the Modules.symvers with and without this
patch and for ia64's defconfig, the only change is:
Before 0x00000000    per_cpu____sn_nodepda   vmlinux
After  0x9d3f3faa    per_cpu____sn_nodepda   vmlinux

per_cpu____sn_nodepda was the original source of my problems.

Signed-off-by: Robin Holt <holt@sgi.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2005-12-26 22:39:55 +01:00
Linus Torvalds 1da177e4c3 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!
2005-04-16 15:20:36 -07:00