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

[greg@kroah.com (Greg KH)]

On Fri, Oct 16, 2015 at 06:40:40AM +0000, Warlich, Christof wrote:
> > 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?

As it doesn't fix an in-kernel issues, I doubt it's worth the effort,
but I'm not the maintainer of this portion of the kernel, so I do not
know if it will be accepted or not, sorry.

good luck!

greg k-h