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

[Warlich, Christof]

> I'll ask, why would you ever want to pass a macro to module_init()?
> 
> We don't like functions to be macros in the kernel, do you have a
> real-world need for this somewhere?  If so, can you show the code?

Yes, certainly: As I said in my first post, I'd like to provide a driver template for a certain type of driver.
To reduce the number of changes when using that template to a minimum, that template looks similar to
something like this:

#define DRIVER_NAME driver_template // Change to your driver's name.

#define _CONCAT(x, y) x##y
#define CONCAT(x, y) _CONCAT(x, y)
#define _STRINGIFY(x) #x
#define STRINGIFY(x) _STRINGIFY(x)

static int CONCAT(DRIVER_NAME, _open)(struct inode *inode, struct file *fp)
{
	...
}

static int CONCAT(DRIVER_NAME, _release)(struct inode *inode, struct file *fp)
{
	...
}

static long CONCAT(DRIVER_NAME, _ioctl)(struct file *fp, unsigned int cmd, unsigned long value)
{
	...
}

static struct file_operations fops = {
	.owner = THIS_MODULE,
	.open = CONCAT(DRIVER_NAME, _open),
	.release = CONCAT(DRIVER_NAME, _release),
	.unlocked_ioctl = CONCAT(DRIVER_NAME, _ioctl),
};

static int __init CONCAT(DRIVER_NAME, _init)(void)
{
	...
}

static void __exit CONCAT(DRIVER_NAME, _exit)(void)
{
	...
}

module_init(CONCAT(DRIVER_NAME, _init));
module_exit(CONCAT(DRIVER_NAME, _exit));

This way, someone using that template to start writing a new driver just needs to change the definition of DRIVER_NAME (besides adding device specific functionality).
Oh, and I'm well aware that all those functions are static, so that no name conflicts would occur if all drivers derived from that template would simply all use the same names,
but doing so may make debugging harder, I'd think.