linux-kernel - Re: [RFC] Reentrant clock sources

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 25 Nov 2008 15:55:01 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Magnus Damm <magnus.damm@...il.com>
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	lethal@...ux-sh.org, johnstul@...ibm.com, mingo@...hat.com,
	tglx@...utronix.de
Subject: Re: [RFC] Reentrant clock sources

* Magnus Damm <magnus.damm@...il.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/