On Mon, Feb 13, 2012 at 03:39:51PM +0100, Jiri Denemark wrote: > 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. Ok, fair enough; I just thought I'd better ask the question. Dave > Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list