Messages in this thread | | | Date | Tue, 11 Jan 2000 12:39:02 +0000 (GMT) | From | Tigran Aivazian <> | Subject | [idea] request_module(const char *fmt, ...); |
| |
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/
| |