On Fri, Feb 10, 2012 at 13:33:47 -0700, Eric Blake wrote: > On 02/10/2012 12:21 PM, Dave Allan wrote: > >> I'm wondering if we're too late for one more API to round out the API we > >> added in this release. Qemu is proposing a new monitor command > >> system_wakeup which lets the host inject a power-button wakeup to a > >> guest that has gone into S3 sleep. Since we added the > >> virDomainPMSuspendForDuration command to put the guest into S3 from the > >> host, I think we need a counterpart API that wakes the guest back up, > >> rather than relying on mouse clicks, serial input, or timeouts doing the > >> job for us. It's a shame that virDomainResume() has no flags argument, > >> and that it is already tied to virDomainSuspend() (aka guest pause), so > >> I'm thinking something like: > >> > >> /* Inject a wakeup into the guest that previously used > >> * virDomainPMSuspendForDuration, rather than waiting for the > >> * previously requested duration (if any) to elapse. */ > >> int virDomainPMWakeup(virDomainPtr dom, unsigned int flags); > > > > Just to throw this out there, could we not simply implement the rest > > of the power states in this API? Kind of late to be asking this > > question, I suppose, but we haven't released this API yet, could we > > change its name to virDomainPMSetPowerStateForDuration? > > Interesting idea! It means we have one call, instead of 2, and 4 PM > states instead of 3 (suspend, hibernate, hybrid, and now wakeup). Of > course, wakeup for duration doesn't make much sense, so we could > explicitly require a 0 duration for the wakeup case. I'm not a big fan of this idea. There are two different things here: suspending (in whatever way) and waking up. I think it makes sense to have separate APIs for them. After all we don't have a virDomainSetState API which we could use to transition domain between lifecycle states (running, shutoff, paused, ...). We have separate APIs for each transition, each doing one "simple" thing and possibly taking different data needed for that transition. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list