[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1248879448.28841.180.camel@desktop>
Date: Wed, 29 Jul 2009 07:57:28 -0700
From: Daniel Walker <dwalker@...o99.com>
To: Martin Schwidefsky <schwidefsky@...ibm.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, 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 ..
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 ..
Daniel
--
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