On Thu, Apr 02, 2015 at 06:32:38PM +0100, Peter Zijlstra wrote:
On Thu, Apr 02, 2015 at 05:53:09PM +0100, Morten Rasmussen wrote:
Could you enlighten me a bit about how to define the arch specific implementation without getting into trouble? I'm failing miserably :(
Hmm, this was not supposed to be difficult.. :/
I wouldn't have thought so, and it turned out not to be...
I thought the arm arch-specific topology.h file was a good place to put the define as it get included in sched.h, so I did a:
#define arch_scale_freq_capacity arm_arch_scale_freq_capacity
However, I have to put a function prototype in the same (or some other included) header file to avoid doing an implicit function definition. arch_scale_freq_capacity() takes a struct sched_domain pointer, so I have to include linux/sched.h which leads to circular dependency between linux/sched.h and topology.h.
Why would you have to include linux/sched.h ?
#define arch_scale_freq_capacity arch_scale_freq_capacity struct sched_domain; extern unsigned long arch_scale_freq_capacity(struct sched_domain *, int cpu);
Would work from you asm/topology.h, right?
Yes, of course, it works fine. It was just me missing the most obvious solution. No need to include linux/sched.h, 'struct sched_domain;' was the bit I was missing. Sorry for the noise.
We can drop the sched_domain pointer as we don't use it, but I'm going to do the same trick for arch_scale_cpu_capacity() as well which does require the sd pointer.
Sure, dropping that pointer is fine.
Finally, is introducing an ARCH_HAS_SCALE_FREQ_CAPACITY or similar a complete no go?
It seems out of style, I'd have to go look for the email thread, but this should more or less be the same no?
The above works just fine, so no need for that anyway :)