From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roger Pau Monne Subject: Re: [PATCH v6 06/13] libxl: convert libxl_device_disk_add to an async op Date: Tue, 26 Jun 2012 16:14:05 +0100 Message-ID: <4FE9D1BD.7040204@citrix.com> References: <1339676475-33265-1-git-send-email-roger.pau@citrix.com> <1339676475-33265-7-git-send-email-roger.pau@citrix.com> <20452.22522.766301.170343@mariner.uk.xensource.com> <4FE9CF7D.3060403@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4FE9CF7D.3060403@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org Roger Pau Monne wrote: >> Isn't the effect of this that if the xs transaction gets a conflict, >> we'll rerun the hotplug scripts, etc. ? I think I may be confused >> here, but I don't understand how this transaction loop is supposed to >> work and how it is supposed to relate to the interaction with other >> domains, scripts, etc. > > Yes I see your point. We should disconnect the device (execute hotplug > scripts) but since the xenstore entries are already gone (because the > transaction is not committed successfully) I don't see anyway to do it, > we cannot execute those scripts if the backend entries have been lost. Sorry, I've made a mistake here, since the transaction is not committed, we never reach the desired state (2), so if the transaction fails no scripts are executed, and we can carry on trying to add the device again.