From: Grover, A. <and...@in...> - 2003-03-31 18:37:02
|
> From: Knut Neumann [mailto:knu...@un...] > as you suggested last year I made the ospmd_gui have a > thermal page. Now > I found the time to clean the patch up and send it to you. Thanks! (BTW we are going to switch from the ACPI CA license to the BSD license, is that OK with you?) > I always thought to transparently export the acpi interface through > ospmd/libpower. That is why I made one struct (PM_THERMAL_DATA) per > zone. Now that seems plain wrong to me. > > As I understand today you want ospmd to gather those > information needed > for power management (policies) from /proc/acpi and export control of > ospmd via libpower - is that right? Yes. I'm assuming the user will be using a GUI-specific PM control panel program, so my thought was that all these would act on the same power policy by using libpower to talk to ospmd. This makes the interface libpower exposes VERY IMPORTANT. It should not change once we lock it down. I think at some point we need to review it (does it have enough information? Too much?). IIRC we also are using internal data structures in it, so we will probably want to fix that. > In conclusion that would rather mean to have access to eg cooling > mode/temperature (in ospmd _and_ libpower) via: > > pm_set_thermal_cooling > pm_get_thermal_cooling > pm_get_thermal_temperature > > to be able to either set cooling mode from the gui directly or have a > policy in ospmd that eg switches cooling mode to active when a certain > temperature is reached. Well, cooling mode is only supposed to be specified by the user, so I don't think ospmd would change it by itself. However, there is a lot of room for ospmd to take the user's preference and then do the right thing based on that. For example, what do we do when the battery gets low? If the user has said to suspend the system when battery reaches 10%, then ospmd needs to track that and make it happen at the right time. Regards -- Andy |