Messages in this thread | | | Subject | Re: [PATCH 2/5] introduce CLOCK_MONOTONIC_RAW | From | john stultz <> | Date | Mon, 17 Mar 2008 19:27:50 -0700 |
| |
On Mon, 2008-03-17 at 19:03 -0700, john stultz wrote: > On Sat, 2008-03-15 at 05:50 +0100, Roman Zippel wrote: > > > @@ -439,6 +475,7 @@ static void clocksource_adjust(s64 offset) > > > void update_wall_time(void) > > > { > > > cycle_t offset; > > > + static u64 raw_snsec; /* shifted raw nanosecnds */ > > > > > > /* Make sure we're fully resumed: */ > > > if (unlikely(timekeeping_suspended)) > > > > IMO that's really a clock property, so this belongs in the clock > > structure. > > (Some day we may want to have multiple active clocks for various purposes > > and thus export multiple raw clocks.) > > I disagree. I think that crufts up the clocksource structure (which is > ideally just a simple hw counter abstraction), with timekeeping state.
Bah. Ok, I've talked myself out of this one.
I still think it crufts up the clocksource structure, but its more consistent that we follow the established cruft (such as the pre-calculated cycle_interval/xtime_interval/raw_interval combo) rather then me trying to arbitrarily draw the line in the sand at this variable.
> I'm still not sold on the multiple clocks with multiple notions of time > idea you keep on bringing up. But if/when we cross that bridge, maybe it > would be better to add a timekeeping_clock mid-layer abstraction that > keeps the clocksource specific timekeeping state. That way we don't add > lots of complexity for the clocksource driver writers to deal with and > we allow the clocksources to be better re-purposed (for maybe more sane > things like performance counters) without getting too bloated.
I still think pulling out all of the non-counter-abstraction bits out of the clocksource and into a mid-level timekeeping_clock structure would still be ideal here, but I'll save our time/energy on that one for another day. :)
thanks -john
| |