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

Re: [Xen-devel] [patch 5/6] frontend device shutdown


  • To: Gerd Hoffmann <kraxel@xxxxxxx>, Xen devel list <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Sat, 19 Aug 2006 13:25:05 +0100
  • Delivery-date: Sat, 19 Aug 2006 05:34:00 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcbDioAtvukU8C99Edu36QANk04WTA==
  • Thread-topic: [Xen-devel] [patch 5/6] frontend device shutdown



On 17/8/06 3:03 pm, "Gerd Hoffmann" <kraxel@xxxxxxx> wrote:

> xenbus_closing_done() behaves differently depending on how the closing
> was triggered.  If it was triggered by the backend the frontend acks the
> removal by going to CLosed.  If it was triggered via device_shutdown()
> the state is set back to "Initializing", to allow a possible new kernel
> instance to reuse the devices (for domU kexec again ;)

I really don't like that distinction very much (moving to Initialising
instead of Closed). The problem is really in the backend, which incorrectly
interprets XenbusStateClosed as a request to completely unregister the
device. The reason it does this is because the control tools signal that
destruction should take place by deleting the frontend directory in
xenstore. This results in xenbus_read_driver_state() returning
XenbusStateClosed, hence the backend drivers have interpreted that state
value as a destruction request from the tools.

I've gone some way to cleaning this up in changeset 11203, which instead has
xenbus_read_driver_state() return XenbusStateUnknown if the frontend
directory is missing. You should use this to distinguish the Closed and
Unkown states in the backend drivers: this will mean that you won't need to
avoid entering state Closed in the frontend drivers.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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