From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: xl dev-detach hangs with missing frontends Date: Fri, 12 Feb 2016 16:56:49 +0000 Message-ID: <20160212165649.GA10534@citrix.com> References: <20160211103749.GA26883@aepfle.de> <20160212140752.GA5427@citrix.com> <20160212145306.GA14753@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20160212145306.GA14753@aepfle.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Olaf Hering Cc: Ian Jackson , Wei Liu , Ian Campbell , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Fri, Feb 12, 2016 at 03:53:06PM +0100, Olaf Hering wrote: > On Fri, Feb 12, Wei Liu wrote: > > > CC'ing other tools maintainer. > > > > On Thu, Feb 11, 2016 at 11:37:49AM +0100, Olaf Hering wrote: > > > How should libxl__initiate_device_generic_remove deal with devices which > > > > I think you meant libxl__initiate_device_remove. There is no function > > called libxl__initiate_device_generic _remove. > > Not yet. > I see. That function is renamed in PVUSB series. > > > have no frontend driver? Right now it moves "state" from either > > > XenbusStateInitialising or XenbusStateInitWait to XenbusStateClosing. > > > Then it expects the backend to move "state" to XenbusStateClosed. This > > > will never happen, at least for netback and scsiback. The result is a 10 > > > second delay. > > > > > > > I don't think there is a way to tell whether there is no frontend driver > > or the frontend driver is just too slow. > > To handle this the code should check the current value of "state". If > its XenbusStateInitialising or XenbusStateInitWait nothing should be > done. Right. The state is reliable for telling whether frontend is connected or not. Wei. > > Olaf