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

[Terry (Sarito) Whatley]

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).

> 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).
> 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 :-).

-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
>>>   
>>
>