From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [patch 5/6] frontend device shutdown Date: Mon, 21 Aug 2006 16:11:25 +0200 Message-ID: <44E9BF0D.3090705@suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Xen devel list List-Id: xen-devel@lists.xenproject.org > 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. Ok, that should work fine for the backend side. But there is another problem on the frontend side: xenbus_probe_node() ignores devices which are not in Initializing state, so it doesn't reprobe devices which are about to disappear. The next kernel should probe them, but the frontend state is still Closing (or Closed) ... I think that was the initial reason to do the jumpback to Initializing (so the new kexec'ed kernel finds an environment identical to the direct boot). That was also the reason to introduce the shutdown_in_progress flag, so I have some way to avoid re-initializing of the device by the old kernel. cheers, Gerd -- Gerd Hoffmann http://www.suse.de/~kraxel/julika-dora.jpeg