AW: parameter of module_init() and module_exit() must not be a macro

[Warlich, Christof]

> Ick, no, don't do that, you will make life much harder for everyone
> involved in the end.  Just write out the code "for real", it's trivial
> to do so, and you aren't really saving anyone anytime as nothing like
> this would ever be acceptable to the upstream kernel developers.
> 
> Really, you aren't saving any time/energy here, the "template" code is
> the easiest part to write, it's what is in those functions that really
> matters.

Ok, agreed, the CONCAT() construct looks a bit strange at first sight, although
things could further be simplified, e.g.:

#define _CONCAT(x, y) x##y
#define CONCAT(x, y) _CONCAT(x, y)
#define _STRINGIFY(x) #x
#define STRINGIFY(x) _STRINGIFY(x)
#define DRIVER_NAMESPACE(x) CONCAT(CONCAT(DRIVER_NAME, _), x)

...

static void __exit DRIVER_NAMESPACE(exit)(void)
{
	...
}

module_init(DRIVER_NAMESPACE(init));
module_exit(DRIVER_NAMESPACE(exit));

But anyhow, as you are most probably right that this would not be accepted
upstream, there is not much point in arguing further whether my example is a
good idea.

I'd still like to make a point if the current implementation of the module_init()
and module_exit() macros is _correct_ though. With the following code snippet:

#define FOO BAR
module_init(FOO);

the current implementation of the module_init() macro would expand to

	static inline initcall_t __inittest(void)		\
	{ return BAR; }					\
	int init_module(void) __attribute__((alias("FOO")));

i.e. we see both FOO and BAR in the expanded code, which is rather unexpected.
The patch that I've suggested would fix that, as the macro would then expand to:

	static inline initcall_t __inittest(void)		\
	{ return BAR; }					\
	int init_module(void) __attribute__((alias("BAR")));

Thus, even when not being able to give an acceptable real world example, my
proposed patch would still enforce the principle of "least surprise". Just consider
this similar to coding standardization patches: It would just improve overall
code quality.

So my initial question remains: How are the chances to get my (code quality
improvement) patch upstream?

Oh, and by the way: Many thanks for taking your precious time answering :-).