|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [PATCH] xl: Support backend domain ID for disks
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
|
|
|
|
|