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

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

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