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 12:08:00 -0400
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Mon, 17 Oct 2011 09:40:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20124.19677.239702.693620@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> <4E9C4BB1.1060506@xxxxxxxxxxxxx> <20124.19677.239702.693620@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 11:42 AM, Ian Jackson wrote:
> Daniel De Graaf writes ("Re: [Xen-devel] [PATCH] xl: Support backend domain 
> ID for disks"):
>> 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?
> 
> No, but they don't currently work, either :-/.  This is certainly
> needed.
> 

If we change the stat() so that it's only done on types that require a file,
then all that is required is to create a "remote-phy" type that does not do
the stat locally. This type would also avoid trying to fill in nodes like
"physical-device" that are derived from the stat(), leaving those to be
filled in by the backend domain.

>> 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). 
> 
> OMG, that's horrible.

Agreed, it's not a viable solution for anything long-term.

>> 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.
> 
> I think that in the New World Order, a driver domain should be told
> the pdev_path and left to get on with it.  So something in the driver
> domain needs to watch xenstore.  Perhaps a BSD-style backendd ?
> 

That would make the most sense. Linux does get events when this part of
xenstore is updated, so it may be possible to fire off the needed events
from udev/hotplug depending on what can be picked up there.

>> 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?
> 
> If we have "backendtype" then we already have squashed together names.
> But let's see what other people say about the colour of this bikeshed.
> 
> Ian.
> 

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