[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |