[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Qemu-devel] [PATCH v2] event: Add source information to SHUTDOWN
On 04/19/2017 05:36 PM, Alistair Francis wrote: > On Wed, Apr 19, 2017 at 3:22 PM, Eric Blake <eblake@xxxxxxxxxx> wrote: >> Libvirt would like to be able to distinguish between a SHUTDOWN >> event triggered solely by guest request and one triggered by a >> SIGTERM or other action on the host. qemu_kill_report() is >> already able to tell whether a shutdown was triggered by a host >> signal (but NOT by a host UI event, such as clicking the X on >> the window), but that information was then lost after being >> printed to stderr. >> >> Enhance the shutdown request path to take a parameter of which >> way it is being triggered, and update ALL callers. It would have >> been less churn to keep the common case with no arguments as >> meaning guest-triggered, and only modified the host-triggered >> code paths, via a wrapper function, but then we'd still have to >> audit that I didn't miss any host-triggered spots; changing the >> signature forces us to double-check that I correctly categorized >> all callers. > With all this churn is it not worth chaning the bool from_guest to an > int that we can expand in future? > > I'm imagining an enum with multiple values for different shutdown > events. At the moment it will just be one for guest and one for host, > but at some point in the future we might want more. Yes, that makes sense. Probably easiest is creating a QMP enum now ( as in { 'enum': 'ShutdownCause', 'data': ['guest', 'host'] } - although such an enum defaults to starting at 0, and the shutdown_requested variable in vl.c would need a tweak to pick a different value when no shutdown is requested. > Not only does this future proof us, but I think it makes it more clear > what you are passing the function instead of just true/false. Under your proposal, it would be qemu_system_shutdown_request(SHUTDOWN_CAUSE_GUEST), which does look a bit nicer. I'll wait for other review comments, but you have given me a good reason to do a v3. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |