|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [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
|
|
|
|
|