WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] xl: Support backend domain ID for disks

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] xl: Support backend domain ID for disks
From: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
Date: Mon, 17 Oct 2011 11:37:21 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Delivery-date: Mon, 17 Oct 2011 09:37:59 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20124.13831.994269.162705@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: National Security Agency
References: <1318461127-6684-1-git-send-email-dgdegra@xxxxxxxxxxxxx> <20124.13831.994269.162705@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2
On 10/17/2011 10:04 AM, Ian Jackson wrote:
> Daniel De Graaf writes ("[Xen-devel] [PATCH] xl: Support backend domain ID 
> for disks"):
>> Allow specification of backend domains for disks, either in the config
>> file or via block-attach
> 
> This is probably going in the right direction but I have some
> questions and observations.
> 
> Firstly, much of the rest of the code in libxl assumes that the
> pdev_path string can (depending on the backend type) be dereferenced
> by libxl.  That is, if libxl is running in dom0, it assumes that the
> block device can be dereferenced in dom0.
> 
> So for this to work properly I think at least you need to investigate
> the backend type selection machinery and the pdev_path validation and
> make sure they are somehow disabled.

Adding the ability to disable the stat() in libxl__device_disk_set_backend
seems like it would be useful separate from setting the backend in order
to support formats where the pdev_path is not a file. Do the iscsi/nbd
backend types already do this somehow?

> 
> Having never done driver domains: how does the backend domain know
> what it is supposed to be doing ?  Does it just get the pdev_path via
> xenstore and do the rest itself ?  Does it get told the backend type ?
> What is the resulting xenstore protocol ?
> 
> Is this a reason to preserve the arrangement whereby the target of
> blkback is set up by a hotplug script, rather than by a script
> executed directly by libxl ?

For the "phy" backend type, libxl can populate this correctly from outside 
the backend as long as it can determine proper device major/minor numbers 
for the backend's kernel (perhaps by sharing the backend's /dev via NFS). 
Other backend types like blktap2 that require scripts to be started will 
require switching back to starting the devices via hotplug. I do think
running the script directly from libxl when possible is a good idea as this
makes it easier to debug.

> Finally, one other relatively minor thing.  I don't think "backend" is
> the appropriate name for "backend domid".  How about "backenddomain" ?
> (This may not be compatible with xm I guess...)
> 

This was chosen to match the backend specification for network devices,
but for disks it is confusing with "backendtype" already taken. Since
smashed-together names are hard to read, would "backend_domain" be a
better choice?

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel