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.
Build failure on port-amd64 - acpiverbose
Sources are up to date as of a few minutes ago. --- dependall-acpiverbose --- /build/netbsd-local/src/sys/dev/acpi/acpi_verbose.c:493: warning: assignment makes pointer from integer without a cast *** [acpi_verbose.o] Error code 1 Probably from this commit: Module Name:src Committed By: jruoho Date: Fri Dec 31 10:23:44 UTC 2010 Modified Files: src/sys/dev/acpi: acpi_pci.c acpi_pci.h acpi_verbose.c Log Message: Move the function that finds a device_t for the corresponding ACPI device node from ACPIVERBOSE to the ACPI PCI code. - | 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 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
Re: CVS commit: src/tests/fs/common
On Fri, Dec 31, 2010 at 06:16:41PM +, Antti Kantee wrote: Module Name: src Committed By: pooka Date: Fri Dec 31 18:16:41 UTC 2010 Modified Files: src/tests/fs/common: h_fsmacros.h Log Message: Introduce r/o tests. They do two mounts: the first one is r/w and runs a generator which primes the fs. The second one is r/o and does the actual testing. Also, introduce a nfsro fstype which does a clientside r/w mount for a r/o server export. requested by yamt (one nfsro test currently fails with EROFS vs. EACCES. Hopefully someone else can debate the correct errno) From what I remember of the NFS protocol, the following 'rules' applied: 1) If you export part of a filesystem, you export all of the filesystem. 2) If you give anyone access, you give everyone access. 3) If you give anyone write access, you give everyone write access. This is all because it is the 'mount' protocol that verifies whether a client has access - so a client that disobeys the mount protocol, or fakes up valid nfs file handles can avoid the access checks. It is possible that netbsd's nfs server does additional checks but they are expensive to do on every nfs request. David -- David Laight: da...@l8s.co.uk
