I suppose a strange macro like this:
#define request_module(fmt,arg...) -EINVAL
could workaround the problems (almost), but that is unacceptable as well
because it causes compiler warnings for code like:
....
-EINVAL;
....
Tigran
On Thu, 13 Jan 2000, Tigran Aivazian wrote:
> Now I found a reason why request_module() can *NOT* be a macro. Ever.
> Because it wouldn't work for the calls like
>
> (void) request_module("ide-blabla");
>
> or
>
> if (request_module("misc-blabla") == 0)
>
> or some others you can easily imagine. It *worked* before only because all
> the calls to request_module() were either surrounded by CONFIG_KMOD or
> were in the form of a very simple:
>
> request_module(modname);
>
> So, having it as macro or not is not a matter of taste. Having it as a
> macro is *wrong*. It is inconsistent, because it assumes the callers
> surround their code with CONFIG_KMOD, but some (e.g. telephony) don't but
> just use it in a "valid" way.
>
> This time I cc'd Linus because this finding puts the last nail on the
> coffin of the "we want macro and not a function" approach and therefore
> proves the validity of my implementation (the patch I sent earlier):
>
> http://www.ocston.org/~tigran/patches/kmod-2.3.40-p1.patch
>
> 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
>
> On Wed, 12 Jan 2000, James Manning wrote:
>
> > [ Wednesday, January 12, 2000 ] Tigran Aivazian wrote:
> > > In cases where it adds substantial overhead
> > > of re-walking through the entire list (e.g. get_fs_type which walks
> > > through file_systems) the caller should (and does) check the return from
> > > request_module() and only does the extra work if it is == 0.
> >
> > But the beauty of the macro method is that you have a much (relatively)
> > smaller kernel as your preprocessor reduces the request_module to -EINVAL
> > at compile-time and you get to let gcc optimize away (dump dead code :)
> > the entire chunk of code... you've saved a branch, cache efficiency, etc..
> >
> > James
> > --
> > Miscellaneous Engineer --- IBM Netfinity Performance Development
> >
>
>
>
>
>
-
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:22 EST