CPUFreq HAL [PSARC/2007/679 FastTrack timeout 12/12/2007]

[Mark Haywood]

Terry (Sarito) Whatley wrote:
> Mark Haywood wrote:
>> Terry (Sarito) Whatley wrote:
>>> Anup Pemmaiah wrote:
>>>> Artem Kachitchkine wrote:
>>>>  
>>>>> ...
>>>>>> The CPUFreq interface is associated with the "computer" device 
>>>>>> object, similar to system power management interface. Since it is 
>>>>>> global there will be just one method call.
>>>>>>       
>>>>> OK, so based on our little q&a, things missing from the interface 
>>>>> table:
>>>>>
>>>>> - DBus interface name (org.freedesktop.Hal.Device.CPUFreq?)
>>>>> - DBus path of the objects that implement that interface 
>>>>> (/org/freedesktop/Hal/devices/computer?)
>>>>> - "processor" capability for processor objects
>>>>> - I think also "cpufreq_control" capability for the computer object
>>>>>     
>>>> Have updated the psarc draft with the missing interfaces. I am 
>>>> pasting below the additional interfaces added to the draft
>>>>
>>>> The processor specific properties interface
>>>>   Interface        Type             Comments
>>>>    ---------------------------------------------------------------
>>>> info.capabilities    string list    value = "processor"
>>>>
>>>>
>>>>     The computer device object specific properties interface. If the 
>>>> property
>>>>     already exists, then the following values will get appended
>>>>
>>>>    Interface        Type             Comments
>>>>    ---------------------------------------------------------------
>>>>    info.capabilities    string list    value = "cpufreq_control"
>>>>    info.interfaces    string list    value = 
>>>> "org.freedesktop.Hal.Device.CPUFreq"
>>>>    info.addons        string list    value = "hald-addon-cpufreq"  
>>>>    D-Bus specific Information
>>>>    ---------------------------
>>>>
>>>>   Interface Name:        org.freedesktop.Hal.Device.CPUFreq
>>>>              Path to device object        
>>>> /org/freedesktop/Hal/devices/computer
>>>>   that implements the
>>>>   interface
>>>>
>>>> Interfaces Imported:
>>>>
>>>>    
>>>> Interface                                                            
>>>>     Comments
>>>  As per PSARC 20005/267, the pm ioctls below are undocumented, 
>>> consolidation private interfaces.
>>> The current case proposes to use /etc/power.conf and pmconfig (both 
>>> documented and committed interfaces)
>>> to control the policy.  Since they already have to parse 
>>> /etc/power.conf to do this, it makes no
>>> sense to bypass /etc/power.conf (via the ioctls listed below) when 
>>> attempting to determine what the current
>>> pm state is.  It would be better to parse the power.conf file to get 
>>> this information, since it
>>> contains the necessary information in a stable format (though one 
>>> that needs more decoding).
>>>  Note that to do what is proposed below would also require adding a 
>>> line to the diagram
>>> in the case materials that bypasses power.conf and pmconfig to go 
>>> directly to the kernel layer ioctl
>>> interface.
>>
>> No, I don't think that it will be sufficient to use the power.conf 
>> file to get the information since the power.conf file does not 
>> necessarily represent the current state of the system.
> By what mechanism do you imagine that the power.conf file gets out of 
> sync with the system state?
> The only one I know is that somebody edited power.conf and didn't run 
> pmconfig.
> As soon as pmconfig is run, that difference will be erased, so it is 
> transient at best.
> (The other, of course, is that somebody has written a program that is 
> messing with
> the state via the ioctls, but if that is the case both you and them are 
> doomed anyhow).

What you say is entirely true, but this problem is not new. dtpower had 
the same problem - display the active system policy or display the one 
currently defined by power.conf. dtpower chose to go the former route 
(using the PM ioctls). Admittedly, dtpower had the ability to pop up a 
warning to the user if the system policy and power.conf were out of sync.

>> The only way to know how the system is currently configured it to ask 
>> the framework.
> If you are going to control policy by editing power.conf and doing a 
> pmconfig, at the point that you
> do the pmconfig the power.conf content and system state will become 
> identical (that is pmconfig's job).
> Since you plan to blow away any difference anyhow, you might as well 
> just start with doing a pmconfig,
> and then use the power.conf file content to indicate the state.  (Or you 
> could say that if the user edits
> power.conf and doesn't do a pmconfig then the behavior is undefined).

GPM/HAL executing pmconfig when it is invoked would be really poor 
behavior. No change should be made to the policy unless the user 
requests a change.

I believe that your last suggestion is the right behavior. If the 
current system policy and the power.conf contents are not in sync then 
HAL should consider the current policy as undefined. I believe HAL will 
have to use the PM ioctls to determine if the system policy and 
power.conf are telling the same story.

>> Since the HAL code resides in the ON consolidation I see no issue with 
>> it using the consolidation private interfaces?
> It seems to me one ought to use the most stable and documented 
> interfaces available,
> given that the code has to do the same inferences either way.  But I 
> don't get to vote,
> I'm only a licensee :-).

And if the interfaces that you suggest we use were sufficient, I'd agree 
with you. Since they are not, I think it is reasonable that we use the 
consolidation private interfaces that were made available by 
PSARC/2005/067. Of course, I don't get to vote either.

If there is a reason that you feel the PM ioctls are likely to change, 
then we should discuss it before this case proceeds any further.

Mark

> -sarito
>>>
>>> thanks,
>>> Terry (Sarito) Whatley
>>>
>>>>    
>>>> ----------------------------------------------------------------------------------------------------------- 
>>>>
>>>>   PM_GET_CPU_THRESHOLD       Used by GetCPUFreqPerformance to 
>>>> determine the
>>>>                                                               
>>>> frequency performance.
>>>>        PM_GET_SYSTEM_THRESHOLD     Used by GetCPUFreqPerformance to 
>>>> determine the
>>>>                                                                       
>>>> frequency performance.
>>>>
>>>>
>>>>    PM_GET_CPUPM_STATE            Used by GetCPUFreqGovernor to 
>>>> determine the
>>>>                                                              current 
>>>> system policy.
>>>>
>>>>    PM_GET_PM_STATE                    Used by GetCPUFreqGovernor to 
>>>> determine the
>>>>                                                              current 
>>>> system policy.
>>>>
>>>>
>>>> The new draft can be found at
>>>> http://sac.eng/arc/PSARC/2007/679/materials/spec.v1.txt
>>>>
>>>> Thanks
>>>> Anup
>>>>  
>>>>> Could you also place a copy of hal-spec.html in the case directory, 
>>>>> because the one at freedesktop.org changes frequently.
>>>>>
>>>>> thanks,
>>>>> -Artem
>>>>>     
>>>>
>>>> _______________________________________________
>>>> opensolaris-arc mailing list
>>>> opensolaris-arc at opensolaris.org
>>>>   
>>>
>>
>