* Peter Zijlstra <pet...@infradead.org> wrote:
> On Thu, Apr 02, 2015 at 07:20:50PM +0530, Viresh Kumar wrote:
> > > Or am I completely missing something?
> >
> > So yes, if we would have done that in tick_program_event(), it would have
> > been a single place for doing this change..
> >
> > But, when Thomas ranted [1] at me on this earlier, he said:
> >
> > "
> > No, we are not doing a state change behind the scene and a magic
> > restore.
> >
> > 2B) Implement the ONESHOT_STOPPED logic and make sure all of the core
> > code is aware of it.
> > "
> >
>
> lkml.org didn't work for me, alternative link:
>
> http://marc.info/?l=linux-kernel&m=139966616803683&w=2
>
> So I've read that (several times) and I thing Thomas meant something
> else.
>
> So I think he disliked what you did to the clockevent layer, not so much
> you touching tick_program_event(). But the last_state thing (which was
> broken), and you imposing the SHUTDOWN policy for everybody.
>
> But with the optional ONESHOT_STOPPED state both those are gone, and
> we'd end up with the much simpler patch below.
>
> Further note that tick-oneshot is the natural place to do this, that is
> the glue layer between the (oneshot) clockevents stuff and the timer
> stuff. Pulling clockevents into hrtimers feels wrong.
>
> Ingo, do you agree with that after reading Thomas' email?
Yeah, I suppose ...
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
