Re: [RFC][patch 02/12] remove clocksource inline functions

[Martin Schwidefsky]

On Wed, 29 Jul 2009 08:57:13 -0600
dwalker@xxxxxxxxxx wrote:

> On Wed, 2009-07-29 at 16:44 +0200, Martin Schwidefsky wrote:
> > On Wed, 29 Jul 2009 08:15:19 -0600
> > dwalker@xxxxxxxxxx wrote:
> > 
> > > > Remove clocksource_read, clocksource_enable and clocksource_disable
> > > > inline functions. No functional change.
> > > > 
> > > 
> > > Your still not really explaining this one, is this suppose to be
> > > cleaner? Or is this related to some other part of your clean up?
> > 
> > The only one of the three inline functions that is a bit more
> > complicated is clocksource_enable() because of the mult_orig logic. But
> > that goes away with a later patch. The function aren't accessors either,
> > they are used exclusively by the timekeeping code. In short, they are
> > useless, don't you think?
> 
> Above is what should go in your patch description .. 

Ok, sounds reasonable.
 
> The reason that I'm not totally into this one is cause these inlines
> help to document to the code..
> 
> If you have ,
> 
> struct clocksource cs;
> 
> then several lines later you have
> 
> cs->read(); 
> 
> vs,
> 
> clocksource_read(cs);
> 
> The later is completely clear, and the former isn't.. Instead of "cs"
> you could pick any obscure name, and read() isn't exactly unique.. So
> really any function in the clocksource structure has the potential for a
> helper, and the inlines don't really cost anything ..

Hmm, you have an object of type struct clocksource and you do
cs->read(cs). If that is not clear enough then I don't know what is. We
do that all over the place in the linux kernel. And I personally find
these useless wrappers rather annoying. I don't like to have to jump to
another place to find out that it just calls the read function of the
object.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/