Re: [tip:core/rcu] rcu: Remove inline from forward-referenced functions

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Tue, Nov 10, 2009 at 02:38:30PM -0800, Joe Perches wrote:
> On Tue, 2009-11-10 at 22:27 +0000, tip-bot for Paul E. McKenney wrote:
> > rcu: Remove inline from forward-referenced functions
> > diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
> > index ef2a58c..c03edf7 100644
> > --- a/kernel/rcutree_plugin.h
> > +++ b/kernel/rcutree_plugin.h
> > @@ -33,7 +33,7 @@ DEFINE_PER_CPU(struct rcu_data, rcu_preempt_data);
> >  /*
> >   * Tell them what RCU they are running.
> >   */
> > -static inline void rcu_bootup_announce(void)
> > +static void rcu_bootup_announce(void)
> >  {
> >  	printk(KERN_INFO
> >  	       "Experimental preemptable hierarchical RCU implementation.\n");
> > @@ -481,7 +481,7 @@ void exit_rcu(void)
> >  /*
> >   * Tell them what RCU they are running.
> >   */
> > -static inline void rcu_bootup_announce(void)
> > +static void rcu_bootup_announce(void)
> >  {
> >  	printk(KERN_INFO "Hierarchical RCU implementation.\n");
> >  }
> 
> non-inline functions in .h files probably aren't a good idea.

;-)

Here are my options:

1.	Have a huge #ifdef in kernel/rcutree.c.  Not going there.

2.	#include kernel/rcutree_plugin.h near the beginning of
	kernel/rcutree.c rather than near the end.  I originally
	had it set up this way, but this results in a large number
	of forward references from kernel/rcutree_plugin.h, which
	turned out to be a real mess.  The current setup is much
	nicer, as the forward references serve to document the
	plug-in functions that are defined in kernel/rcutree_plugin.h.

3.	Leave in the "inline" declarations on the function definitions.
	Although all the compilers that -I- use are quite happy with
	this, some people's compilers complain.  So this is not good,
	either.

Please note that kernel/rcutree_plugin.h is internal to RCU -- only
kernel/rcutree.c includes it, so there is no possibility of conflicting
definitions.

Any options that I am missing?

							Thanx, Paul