p71924506
/
linux_old1
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
linux_old1/scripts/genksyms/keywords.gperf

62 lines
1.6 KiB
Plaintext
Raw Normal View History

genksyms: pass hash and lookup functions name and target language though the input file Renaming hash and lookup functions on the command line would reduces its genericity. Use the .gperf file to pass this information. Do the same for the target language. Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
2011-05-05 09:18:27 +08:00
%language=ANSI-C
%define hash-function-name is_reserved_hash
%define lookup-function-name is_reserved_word
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-17 06:20:36 +08:00
%{
genksyms: Mark is_reserved_word static 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-10-16 03:58:40 +08:00
struct resword;
static const struct resword *is_reserved_word(register const char *str, register unsigned int len);
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-17 06:20:36 +08:00
%}
struct resword { const char *name; int token; }
%%
EXPORT_SYMBOL, EXPORT_SYMBOL_KEYW
EXPORT_SYMBOL_GPL, EXPORT_SYMBOL_KEYW
[PATCH] add EXPORT_SYMBOL_GPL_FUTURE() 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-03-21 05:17:13 +08:00
EXPORT_SYMBOL_GPL_FUTURE, EXPORT_SYMBOL_KEYW
genksyms: properly consider EXPORT_UNUSED_SYMBOL{,_GPL}() 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-12-06 04:20:50 +08:00
EXPORT_UNUSED_SYMBOL, EXPORT_SYMBOL_KEYW
EXPORT_UNUSED_SYMBOL_GPL, EXPORT_SYMBOL_KEYW
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-17 06:20:36 +08:00
__asm, ASM_KEYW
__asm__, ASM_KEYW
__attribute, ATTRIBUTE_KEYW
__attribute__, ATTRIBUTE_KEYW
__const, CONST_KEYW
__const__, CONST_KEYW
kbuild: __extension__ support in genksyms (fix unknown CRC warning) Recently the __extension__ keyword has been introduced in the kernel. Teach genksyms about this keyword so it can generate correct CRC for exported symbols that uses a symbol marked __extension__. For now only the typedef variant: __extension__ typedef ... is supported. Later we may add more variants as needed. This patch contains the actual source file changes. The following patch will hold modifications to the generated files (*_shipped) and only after the second patch the fix has effect. Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2007-08-29 02:28:55 +08:00
__extension__, EXTENSION_KEYW
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-17 06:20:36 +08:00
__inline, INLINE_KEYW
__inline__, INLINE_KEYW
__signed, SIGNED_KEYW
__signed__, SIGNED_KEYW
genksyms: fix typeof() handling Recent increased use of typeof() throughout the tree resulted in a number of symbols (25 in a typical distro config of ours) not getting a proper CRC calculated for them anymore, due to the parser in genksyms not coping with several of these uses (interestingly in the majority of [if not all] cases the problem is due to the use of typeof() in code preceding a certain export, not in the declaration/definition of the exported function/object itself; I wasn't able to find a way to address this more general parser shortcoming). The use of parameter_declaration is a little more relaxed than would be ideal (permitting not just a bare type specification, but also one with identifier), but since the same code is being passed through an actual compiler, there's no apparent risk of allowing through any broken code. Otoh using parameter_declaration instead of the ad hoc "decl_specifier_seq '*'" / "decl_specifier_seq" pair allows all types to be handled rather than just plain ones and pointers to plain ones. Signed-off-by: Jan Beulich <jbeulich@suse.com> Cc: Michal Marek <mmarek@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-04-04 05:46:37 +08:00
__typeof, TYPEOF_KEYW
__typeof__, TYPEOF_KEYW
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-17 06:20:36 +08:00
__volatile, VOLATILE_KEYW
__volatile__, VOLATILE_KEYW
kbuild/genksyms: handle va_list type genksyms currently does not handle va_list. Add the __builtin_va_list keyword as a type. This reduces the amount of syntax errors thrown, but so far no export symbol has a type with a va_list argument, so there is currently no bug in the end result. Note: this patch does not regenerate shipped parser files. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-11-24 00:41:39 +08:00
__builtin_va_list, VA_LIST_KEYW
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-17 06:20:36 +08:00
# According to rth, c99 defines _Bool, __restrict, __restrict__, restrict. KAO
_Bool, BOOL_KEYW
_restrict, RESTRICT_KEYW
__restrict__, RESTRICT_KEYW
restrict, RESTRICT_KEYW
asm, ASM_KEYW
# attribute commented out in modutils 2.4.2. People are using 'attribute' as a
# field name which breaks the genksyms parser. It is not a gcc keyword anyway.
# KAO.
# attribute, ATTRIBUTE_KEYW
auto, AUTO_KEYW
char, CHAR_KEYW
const, CONST_KEYW
double, DOUBLE_KEYW
enum, ENUM_KEYW
extern, EXTERN_KEYW
float, FLOAT_KEYW
inline, INLINE_KEYW
int, INT_KEYW
long, LONG_KEYW
register, REGISTER_KEYW
short, SHORT_KEYW
signed, SIGNED_KEYW
static, STATIC_KEYW
struct, STRUCT_KEYW
typedef, TYPEDEF_KEYW
genksyms: fix typeof() handling Recent increased use of typeof() throughout the tree resulted in a number of symbols (25 in a typical distro config of ours) not getting a proper CRC calculated for them anymore, due to the parser in genksyms not coping with several of these uses (interestingly in the majority of [if not all] cases the problem is due to the use of typeof() in code preceding a certain export, not in the declaration/definition of the exported function/object itself; I wasn't able to find a way to address this more general parser shortcoming). The use of parameter_declaration is a little more relaxed than would be ideal (permitting not just a bare type specification, but also one with identifier), but since the same code is being passed through an actual compiler, there's no apparent risk of allowing through any broken code. Otoh using parameter_declaration instead of the ad hoc "decl_specifier_seq '*'" / "decl_specifier_seq" pair allows all types to be handled rather than just plain ones and pointers to plain ones. Signed-off-by: Jan Beulich <jbeulich@suse.com> Cc: Michal Marek <mmarek@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-04-04 05:46:37 +08:00
typeof, TYPEOF_KEYW
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-17 06:20:36 +08:00
union, UNION_KEYW
unsigned, UNSIGNED_KEYW
void, VOID_KEYW
volatile, VOLATILE_KEYW