aboutsummaryrefslogtreecommitdiffstats
path: root/scripts/genksyms/keywords.c_shipped
Commit message (Collapse)AuthorAgeFilesLines
* genksyms: properly consider EXPORT_UNUSED_SYMBOL{,_GPL}()Jan Beulich2009-12-121-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>
* genksyms: Mark is_reserved_word staticJosh Triplett2009-11-151-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>
* Revert "kbuild: strip generated symbols from *.ko"Sam Ravnborg2009-01-141-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>
* allow stripping of generated symbols under CONFIG_KALLSYMS_ALLJan Beulich2008-12-191-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>
* kbuild: apply genksyms changesSam Ravnborg2007-10-121-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>
* [PATCH] add EXPORT_SYMBOL_GPL_FUTURE()Greg Kroah-Hartman2006-03-201-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>
* kbuild: Create _shipped files for genksymsSam Ravnborg2005-12-261-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>
* Linux-2.6.12-rc2Linus Torvalds2005-04-161-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!