[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

> 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.

> 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 ?

> 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.