aboutsummaryrefslogtreecommitdiffstats
path: root/scripts/genksyms/keywords.c_shipped
AgeCommit message (Collapse)AuthorFilesLines
2011-06-09genksym: regen parserArnaud Lacombe1-220/+0
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
2009-12-12genksyms: properly consider EXPORT_UNUSED_SYMBOL{,_GPL}()Jan Beulich1-94/+97
Despite being unused these should also get a CRC calculated. Primarily I view this as a consistency thing. But I also think this is one of the reasons why __crc_* need to be weak (which I think should be avoided, and hence we should have the goal to eliminate this so that failure to calculate a proper CRC for a symbol causes the build to fail). Signed-off-by: Jan Beulich <jbeulich@novell.com> Cc: Anibal Monsalve Salazar <anibal@debian.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Michal Marek <mmarek@suse.cz>
2009-11-15genksyms: Mark is_reserved_word staticJosh Triplett1-45/+50
The genksyms keyword gperf hash provides a function is_reserved_word. genksyms #includes the resulting generated file keywords.c, so the function gets used only in the same source file that defines it. Mark is_reserved_word static, and regenerate the corresponding generated file. Signed-off-by: Josh Triplett <josh@joshtriplett.org>
2009-01-14Revert "kbuild: strip generated symbols from *.ko"Sam Ravnborg1-96/+93
This reverts commit ad7a953c522ceb496611d127e51e278bfe0ff483. And commit: ("allow stripping of generated symbols under CONFIG_KALLSYMS_ALL") 9bb482476c6c9d1ae033306440c51ceac93ea80c These stripping patches has caused a set of issues: 1) People have reported compatibility issues with binutils due to lack of support for `--strip-unneeded-symbols' with objcopy 2.15.92.0.2 Reported by: Wenji 2) ccache and distcc no longer works as expeced Reported by: Ted, Roland, + others 3) The installed modules increased a lot in size Reported by: Ted, Davej + others Reported-by: Wenji Huang <wenji.huang@oracle.com> Reported-by: "Theodore Ts'o" <tytso@mit.edu> Reported-by: Dave Jones <davej@redhat.com> Reported-by: Roland McGrath <roland@redhat.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2008-12-19allow stripping of generated symbols under CONFIG_KALLSYMS_ALLJan Beulich1-93/+96
Building upon parts of the module stripping patch, this patch introduces similar stripping for vmlinux when CONFIG_KALLSYMS_ALL=y. Using CONFIG_KALLSYMS_STRIP_GENERATED reduces the overhead of CONFIG_KALLSYMS_ALL from 245k/310k to 65k/80k for the (i386/x86-64) kernels I tested with. The patch also does away with the need to special case the kallsyms- internal symbols by making them available even in the first linking stage. While it is a generated file, the patch includes the changes to scripts/genksyms/keywords.c_shipped, as I'm unsure what the procedure here is. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2007-10-12kbuild: apply genksyms changesSam Ravnborg1-90/+90
This patch updates the _shipped files for genksyms. See previous patch for actual functional changes. Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2006-03-20[PATCH] add EXPORT_SYMBOL_GPL_FUTURE()Greg Kroah-Hartman1-45/+46
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>
2005-12-26kbuild: Create _shipped files for genksymsSam Ravnborg1-72/+138
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-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds1-0/+145
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!

Privacy Policy