Re: CVS commit: src/etc/powerd/scripts
On Fri, Dec 31, 2010 at 12:51:24PM -0600, David Young wrote: IMO, we should put the system to sleep by sending a power-saving/wakeup-latency goal and a set of waking events (e.g., keystroke, mouse movement, LAN activity) to the root device_t using drvctl. To put any smaller set of devices to sleep, send the goal wake events to some subtree. FWIW, the sleep states that ACPI names are not sufficient even to describe all of the potential sleep states of ACPI hardware. I have a laptop that's perfectly capable of an S3-like sleep, but the ACPI BIOS doesn't support S3, and the HDD is not formatted properly for the S4 sleep. I would still make the distinction between system sleep and device sleep. It seems to me that you describe above the latter. In the former you still need to call the machine-dependent suspend-sequences at some point. There is nothing quite like ACPI when it comes to jargon. The actual device power states are represented as D-states, which range from D0 (fully on) to D3 (fully off). If I recall correctly, the same abstraction is used in the USB or PCI specifications. As I've noted before, we lack a representation for this in device_t. - Jukka.
Re: CVS commit: src/etc/powerd/scripts
On 31.12.2010 11:10, Jukka Ruohonen wrote: On Fri, Dec 31, 2010 at 11:01:08AM +0100, Jean-Yves Migeon wrote: I am using machdep.sleep_state as node to put a domU into suspend mode. Up to now, putting sleep_state under machdep allowed powerd(8) sleep_button to be used regardless of the environment (eg. ACPI sleep or Xen domU sleep). So Xen uses a *machine-dependent* sysctl(8) variable for purposes entirely different from the intended one? machine-dependent: yes for purposes entirely different from the intended one: not really, purpose is arguably the same, put system into sleep (sleep state being not well defined, I admit). It's only in my local tree though. This can be done in entirely different ways, nothing is set in stone. The side effect of your change is that the sleep_state node will move under hw.acpi, which is not right in Xen domU case. While retiring sleep_state from machdep goes in the right direction IMHO, will it be replaced by a MI interface to put a system into sleep, as it is not a feature specific to ACPI? Definitely agreed. Maybe we could steal zzz(8) from APM? Seems reasonable to me. We could have a more featureful binary later, and just alias zzz(8) to it. Generally, most of the problems (the mess) in the area of power management have been directly caused by the lack of proper MI interfaces and the overall lack of planning. The move towards sysmon_pswitch(9), pmf(9), and powerd(8) were a step to the right direction; the mistakes done with the i386-specific apm(4) should not be repeated. Of course not; that's why I am asking. -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: CVS commit: src/etc/powerd/scripts
On Fri, Dec 31, 2010 at 11:29:23AM +0100, Jean-Yves Migeon wrote: Seems reasonable to me. We could have a more featureful binary later, and just alias zzz(8) to it. We have ready ioctl-facilities in sysmon's sysmon_power.c. I believe it was originally intended by the author that MD code should use the sysmon_power_settype() function to register a power-backend (ACPI, APM, Xen, PowerBook, and so on). Extending this idea seems like a plausible route. - Jukka.
Re: CVS commit: src/etc/powerd/scripts
On Fri, 31 Dec 2010, Jukka Ruohonen wrote: On Fri, Dec 31, 2010 at 11:29:23AM +0100, Jean-Yves Migeon wrote: Seems reasonable to me. We could have a more featureful binary later, and just alias zzz(8) to it. We have ready ioctl-facilities in sysmon's sysmon_power.c. I believe it was originally intended by the author that MD code should use the sysmon_power_settype() function to register a power-backend (ACPI, APM, Xen, PowerBook, and so on). Extending this idea seems like a plausible route. Yes. However, the current implementation is simply a text string with no defined semantics. A back-end is able to set the value, and it can be retrieved via the POWER_IOC_GET_TYPE ioctl, but otherwise nothing uses the value. - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: CVS commit: src/etc/powerd/scripts
On Fri, Dec 31, 2010 at 04:54:47AM -0800, Paul Goyette wrote:
However, the current implementation is simply a text string with no
defined semantics. A back-end is able to set the value, and it can be
retrieved via the POWER_IOC_GET_TYPE ioctl, but otherwise nothing uses
the value.
Sure, I mean the idea, not the actual existing code. Something simple as
sysmon_pswitch(9). Say
struct sysmon_sleep {
const char *smpsl_name;
void *smpsl_arg;
void(*smpsl_func)(void *, int);
};
int sysmon_sleep_register(struct sysmon_sleep *);
int sysmon_sleep_unregister(struct sysmon_sleep *);
And the smpsl::smpsl_func(arg, state) would be called from an ioctl, invoked
by the zzz(8) program.
- Jukka.
Re: CVS commit: src/etc/powerd/scripts
On Fri, Dec 31, 2010 at 11:01:08AM +0100, Jean-Yves Migeon wrote: On 31.12.2010 10:36, Jukka Ruohonen wrote: Module Name:src Committed By: jruoho Date: Fri Dec 31 09:36:15 UTC 2010 Modified Files: src/etc/powerd/scripts: sleep_button Log Message: Use hw.acpi.sleep.state instead of machdep.sleep_state. And so it begins :) I am using machdep.sleep_state as node to put a domU into suspend mode. Up to now, putting sleep_state under machdep allowed powerd(8) sleep_button to be used regardless of the environment (eg. ACPI sleep or Xen domU sleep). While retiring sleep_state from machdep goes in the right direction IMHO, will it be replaced by a MI interface to put a system into sleep, as it is not a feature specific to ACPI? IMO, we should put the system to sleep by sending a power-saving/wakeup-latency goal and a set of waking events (e.g., keystroke, mouse movement, LAN activity) to the root device_t using drvctl. To put any smaller set of devices to sleep, send the goal wake events to some subtree. FWIW, the sleep states that ACPI names are not sufficient even to describe all of the potential sleep states of ACPI hardware. I have a laptop that's perfectly capable of an S3-like sleep, but the ACPI BIOS doesn't support S3, and the HDD is not formatted properly for the S4 sleep. Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933
Re: CVS commit: src/etc/powerd/scripts
On 31.12.2010 19:51, David Young wrote: IMO, we should put the system to sleep by sending a power-saving/wakeup-latency goal and a set of waking events (e.g., keystroke, mouse movement, LAN activity) to the root device_t using drvctl. To put any smaller set of devices to sleep, send the goal wake events to some subtree. I haven't looked at the details of the ioctl(), but I would expect it to be used against /dev/drvctl, no? This seems plausible to me; at least, suspend/sleep should be part of pmf(9) (even in my Xen's case, all driver sleep/wake coded uses pmf(9)). FWIW, the sleep states that ACPI names are not sufficient even to describe all of the potential sleep states of ACPI hardware. I have a laptop that's perfectly capable of an S3-like sleep, but the ACPI BIOS doesn't support S3, and the HDD is not formatted properly for the S4 sleep. -- Jean-Yves Migeon jeanyves.mig...@free.fr
