Dear Horst,
I thought of exactly what you suggest but could not implement it. I.e. I
did not know how to do macros with variable number of arguments. This is
why I resorted to having always a function call and did not even mention
the macro approach in the original suggestion.
Thanks,
------
Tigran A. Aivazian | http://www.sco.com
Escalations Research Group | tel: +44-(0)1923-813796
Santa Cruz Operation Ltd | http://www.ocston.org/~tigran
On Tue, 11 Jan 2000, Horst von Brand wrote:
> Tigran Aivazian <tigran@sco.COM> said:
>
> [...]
>
> > 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.)
>
> Nope. Place:
>
> #ifdef CONFIG_KMOD
> int request_module(const char *fmt, ...)
> #else
> #define request_module(whatever, magic, gcc, demands, for, ...) /* Nothing */
> #endif
>
> into a selected .h, and a matching:
>
> #ifdef CONFIG_KMOD
> int request_module(const char *fmt, va_arg args)
> {
> /* ... */
> }
> #endif
>
> in some random .c
>
> > 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.
>
> Not in my design... and AFAIU CONFIG_KMOD does influence quite a bit more
> than just this, so this point would be moot. I'm more wary of random
> #ifdef all over the place than to have to recompile something anyway.
> --
> Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl
> Departamento de Informatica Fono: +56 32 654431
> Universidad Tecnica Federico Santa Maria +56 32 654239
> Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
>
-
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:19 EST