[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090729173231.012d0b89@skybase>
Date: Wed, 29 Jul 2009 17:32:31 +0200
From: Martin Schwidefsky <schwidefsky@...ibm.com>
To: dwalker@...o99.com
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
john stultz <johnstul@...ibm.com>
Subject: Re: [RFC][patch 02/12] remove clocksource inline functions
On Wed, 29 Jul 2009 08:57:13 -0600
dwalker@...o99.com wrote:
> On Wed, 2009-07-29 at 16:44 +0200, Martin Schwidefsky wrote:
> > On Wed, 29 Jul 2009 08:15:19 -0600
> > dwalker@...o99.com 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists