Re: [idea] request_module(const char *fmt, ...);

[Tigran Aivazian]

just a final confirmation (before I start to irritate someone with a
multitude of mails) - although I still think macro approach is
unacceptable, using static inline (thanks to David for pointing out) is
acceptable but leaves one final question which can only be answered by the
maker (of decisions):

  Q. What is the right design decision for Linux - to have a CONFIG_KMOD
     dependency in the header that declares request_module() or to have
     an extra function call in a non-performance critical code path that
     invokes request_module() but avoid the dependency?

I use Stalin's expression "both are better" :) and leave the question to
Linus, if he find a minute to answer it.

Regards,
------
Tigran A. Aivazian           | http://www.sco.com
Escalations Research Group   | tel: [phone]
Santa Cruz Operation Ltd     | http://www.ocston.org/~tigran

On Thu, 13 Jan 2000, Tigran Aivazian wrote:

> 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: [phone]
> > 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
> > > 
> > 
> > 
> > 
> > 
> > 
> 
> 
>