[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1227669624.6298.11.camel@localhost>
Date: Tue, 25 Nov 2008 19:20:24 -0800
From: john stultz <johnstul@...ibm.com>
To: Ingo Molnar <mingo@...e.hu>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Magnus Damm <magnus.damm@...il.com>,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
lethal@...ux-sh.org, mingo@...hat.com
Subject: Re: [RFC] Reentrant clock sources
On Wed, 2008-11-26 at 04:07 +0100, Ingo Molnar wrote:
> * Thomas Gleixner <tglx@...utronix.de> wrote:
>
> > > + cycle_t (*vread)(struct clocksource *cs);
> >
> > This is crap. vread can not access the clocksource.
>
> i think 'reentrant' in the sense of creating self-sufficient driver
> entities. vread wont (and shouldnt) call ->vread() recursively - but
> it might want to access fields on the clocksource.
I think Thomas' issue is that vread() *cannot* access fields on the
clocksource (since vread has to be careful not to access any
non-vsyscall mapped memory).
However not all clocksources use vread(), but really I'm not quite clear
on what one would want to access in the clocksource structure when
making a ->read() call.
So maybe a further description of what specific need motivates this
change would be helpful? The brief description of power management
doesn't quite click in my head yet.
thanks
-john
--
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