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/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:18 EST