[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090729184444.3937807a@skybase>
Date: Wed, 29 Jul 2009 18:44:44 +0200
From: Martin Schwidefsky <schwidefsky@...ibm.com>
To: Will Newton <will.newton@...il.com>
Cc: dwalker@...o99.com, 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 18:27:54 +0200
Martin Schwidefsky <schwidefsky@...ibm.com> wrote:
> On Wed, 29 Jul 2009 16:36:46 +0100
> Will Newton <will.newton@...il.com> wrote:
>
> > On Wed, Jul 29, 2009 at 4:32 PM, Martin
> > Schwidefsky<schwidefsky@...ibm.com> wrote:
> >
> > > 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.
> >
> > An argument for the helper is that it eases grepability. Sure you can
> > search for "->read" but that's going to turn up all kinds of
> > non-clocksource code as well. grep clocksource_read will get you
> > exactly what you want.
>
> That would make sense if the clocksource_read calls are littered all
> over the kernel source. But they are not, the only user is
> timekeeping.c
And What I find odd as well is e.g. this:
offset = (clocksource_read(clock) - clock->cycle_last) & clock->mask
A mixture of a wrapper to get something out of the clock and a direct
access to other fields of the clocksource. Either it is wrapped or it
isn't, no? A proper wrapper would do all of the above and not just the
call over the read function pointer.
--
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