From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>
Subject: Re: [PATCH v1 06/12] libxl: add support for different
 hotplug interfaces
Date: Fri, 15 Mar 2013 12:36:45 +0100
Message-ID: <514307CD.9090801@citrix.com>
References: <1358963317-10221-1-git-send-email-roger.pau@citrix.com>
	<1358963317-10221-7-git-send-email-roger.pau@citrix.com>
	<20800.42628.553623.496721@mariner.uk.xensource.com>
	<5142FFEB.8060208@citrix.com>
	<20803.1239.777380.793369@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <20803.1239.777380.793369@mariner.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On 15/03/13 12:24, Ian Jackson wrote:
> Roger Pau Monne writes ("Re: [Xen-devel] [PATCH v1 06/12] libxl: add support for different hotplug interfaces"):
>> Right, I've added a new xenstore path that has the following nomenclature:
>>
>> /libxl/<domid>/hotplug/status/<devid>
> 
> That sounds plausible.  What's the value ?

There's only one value:

/libxl/<domid>/hotplug/status/<devid>/backend_domid = <backend_dom>

That's all we need to be able to fill a libxl__device structure. I'm
also thinking that it might be prudent to use

/libxl/<domid>/hotplug/status/vbd/<devid>/backend_domid = <backend_dom>

Right now vbds are the only users of the new hotplug interface, but who
knows if we might want to use it for nics in the future too.

> 
>> This path is created after the device has been prepared, and is cleaned
>> after the device has been unprepared. It only contains the necessary
>> information to be able to fill a libxl__device struct.
> 
> I think it needs to be created before you start preparation, so that
> preparation attempts which crash halfway through are recorded.

Yes, I was also thinking about it after sending the reply...