[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Qemu-devel] [PATCH v7 2/5] shutdown: Prepare for use of an enum in reset/shutdown_request

Eric Blake <eblake@xxxxxxxxxx> writes:

> We want to track why a guest was shutdown; in particular, being able
> to tell the difference between a guest request (such as ACPI request)
> and host request (such as SIGINT) will prove useful to libvirt.
> Since all requests eventually end up changing shutdown_requested in
> vl.c, the logical change is to make that value track the reason,
> rather than its current 0/1 contents.
> Since command-line options control whether a reset request is turned
> into a shutdown request instead, the same treatment is given to
> reset_requested.
> This patch adds an internal enum ShutdownCause that describes reasons
> that a shutdown can be requested, and changes qemu_system_reset() to
> pass the reason through, although for now nothing is actually changed
> with regards to what gets reported.  The enum could be exported via
> QAPI at a later date, if deemed necessary, but for now, there has not
> been a request to expose that much detail to end clients.
> For the most part, we turn 0 into SHUTDOWN_CAUSE_NONE, and 1 into
> SHUTDOWN_CAUSE_HOST_ERROR; the only specific case where we have enough
> information right now to use a different value is when we are reacting
> to a host signal.  It will take a further patch to edit all call-sites
> that can trigger a reset or shutdown request to properly pass in any
> other reasons; this patch includes FIXMEs to point such places out.

If you need to respin the patch for some other reason, consider
replacing FIXME by TODO, because nothing's actually broken here.

> qemu_system_reset() trades its 'bool report' parameter for a
> 'ShutdownCause reason', with all non-zero values having the same
> effect; this lets us get rid of the weird #defines for VMRESET_*
> as synonyms for bools.
> Signed-off-by: Eric Blake <eblake@xxxxxxxxxx>

Reviewed-by: Markus Armbruster <armbru@xxxxxxxxxx>

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.