aboutsummaryrefslogtreecommitdiff
path: root/scripts/genksyms
AgeCommit message (Collapse)Author
2006-03-20[PATCH] add EXPORT_SYMBOL_GPL_FUTURE()Greg Kroah-Hartman
This patch adds the ability to mark symbols that will be changed in the future, so that kernel modules that don't include MODULE_LICENSE("GPL") and use the symbols, will be flagged and printed out to the system log. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-01gitignore: misc filesBrian Gerst
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>
2005-12-26kbuild: Create _shipped files for genksymsSam Ravnborg
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-26kbuild: Fix genksyms handling of DEFINE_PER_CPU(struct foo_s *, bar);Robin Holt
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-04-16Linux-2.6.12-rc2Linus Torvalds
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!