Messages in this thread | | | Date | Tue, 11 Jan 2000 21:29:10 +0100 | From | Pauline Middelink <> | Subject | Re: [idea] request_module(const char *fmt, ...); |
| |
On Tue, Jan 11, 2000 at 12:41:40PM +0000, Tigran Aivazian wrote: > 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.
You could refine this idea by making it a macro, which resolves into nothingness if CONFIG_KMOD is undefined. The function called in the macro (__request_module?) is also not compiled if CONFIG_KMOD is not set. (Yes, you can do varargs in a macro, use ...)
> 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/
Met vriendelijke groet, Pauline Middelink -- PGP Key fingerprint = DE 6B D0 D9 19 AD A7 A0 58 A3 06 9D B6 34 39 E2 For more details look at my website http://www.polyware.nl/~middelink
- 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/
| |