I forgot to add it is clear that the compiler does *NOT* optimize the
chunk away even if request_module() is a nop, so there *is* some
optimization gained by my idea in comparison to simply dropping
#ifdef/#endif.
On Tue, 11 Jan 2000, Tigran Aivazian wrote:
> Hi guys,
>
> Here is the idea:
>
> Instead of current way of switching request_module() depending on
> CONFIG_KMOD inside <linux/kmod.h> and having each driver contain a block
> of code like this (see e.g. fs/block_device.c:get_blkfops())
>
>
> #ifdef CONFIG_KMOD
> if (!blkdevs[major].bdops) {
> char name[20];
> sprintf(name, "block-major-%d", major);
> request_module(name);
> }
> #endif
>
> have a request_module() function with printf()-like syntax inside
> kmod.c:
>
> int request_module(const char *fmt, ...)
> {
> #ifdef CONFIG_KMOD
> va_list args;
> ....
> #else
> return -1;
> #endif
> }
>
> so, the drivers just call request_module("block-major-%d", major);
>
> Disadvantage:
>
> 0. an extra function call even if CONFIG_KMOD is not defined. This is not
> serious as request_module() is never called on a hot path (usually opening
> a device etc.)
>
> Advantages:
>
> 0. Code is not polluted with a multitude of #ifdef CONFIG_KMOD, thus
> making disassembly output look more immediately recognizeable.
>
> 1. No dependency on CONFIG_KMOD spread around the entire kernel. So, if
> you reconfigure the kernel changing CONFIG_KMOD, only the kernel/kmod.c is
> recompiled.
>
> Let me know your ideas and I shall knock up a patch this evening, if your
> feedback is positive.
>
> Regards,
> ------
> Tigran A. Aivazian | http://www.sco.com
> Escalations Research Group | tel: +44-(0)1923-813796
> Santa Cruz Operation Ltd | http://www.ocston.org/~tigran
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:17 EST