Re: [RFC] Reentrant clock sources

[Ingo Molnar]

* Magnus Damm <magnus.damm@xxxxxxxxx> wrote:

> Hi everyone,
> 
> Is there any special reason behind the non-reentrant clock source 
> code? I'm writing some timer help code and getting the struct 
> clocksource as argument to the callbacks would make the code much 
> cleaner and better.

No, there's no real reason, and cleaner code is welcome :-)

Historically most clocksource drivers started out as static and 
standalone entities and hence they always knew how to access their own 
data structures. Passing in cs and generalizing it along that line is 
certainly cleaner.

I'd suggest to not do this by wide-scale breakage of the ->read() API 
though: please introduce a ->read2() method instead, and extend GTOD 
to make use of it if it's present. This way we can gradually migrate 
to ->read2() and then remove the ->read() method atomically once the 
conversion has been finished.

> Extending the callbacks to be able to start and stop clock sources 
> for improved power management would be good too in my opinion. Any 
> thoughts?
> 
> I realize that there are quite a few clock source drivers that need 
> to be modified, any recommendation on which tree to do it against 
> and how to split up the patch? Thanks.

the timer tree is in tip/auto-timers-next, integrated into tip/master:

    http://people.redhat.com/mingo/tip.git/README

and also propagated towards linux-next. Not much is pending at the 
moment so you can work against -git too if you prefer that.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/