On Wednesday, June 01, 2016 04:12:43 PM Viresh Kumar wrote:
On 01-06-16, 00:50, Rafael J. Wysocki wrote:
I'm not particularly liking this due to the possible confusion that may result from it.
I have gotten rid of most of it now in V2.
Perhaps we can require drivers implementing ->fast_switch to sort their frequency tables to start with?
I wasn't *only* concerned about the fast-switch case, but the case of normal governors that we use today. After all that's what everybody is using right now.
Sure, but the "to start with" part of my question was essential.
The ordering didn't matter before, so drivers may do silly things related to it and those may break if we try to change the rules wholesale.
In turn, if the (prospective) ->fast_switch users are required to clean up their stuff while working on implementig it, we could avoid that breakage, or at least some of it.
And I feel (Maybe you as well), that we are better off using a single optimized path for all cases. Otherwise things start getting too messy too soon.
Or maybe make the core check whether or not the table is sorted
Platforms are already broken for this, and so wouldn't be possible to check for existing governors.
I really don't know what you wanted to say here.
and in what order and handle it accordingly?
We should really be handling a single order to avoid complications in it :)
I'm not sure how complicated it would be to be honest. The sorted cases are both very similar and it should be possible to handle them both in the same code regardless of the direction. The unsorted case is special, but that's a matter of an extra branch per function.
Anyway, I agree that using one ordering would be cleaner, but I'm sort of concerned about how painful the switch-over may be to the users.
Thanks, Rafael