On Mon, Jun 12, 2006 at 11:19:00PM +0100, Daniel P. Berrange wrote:
I'm looking to get more of the test driver backend working, and so decided it was time to audit the state of the driver backend infrastructure. There are a couple of areas which could do with some work:
* Driver specific data. The virConnect & virDomain structs have explicit fields for Xen related data:
virConnect:
int handle; /* internal handle used for hypercall */ struct xs_handle *xshandle; /* handle to talk to the xenstore */
virDomain:
int handle; /* internal handle for the domnain ID */
One idea for resolving this is to have an array of slots, one per drivers in which drivers can store data they need.
void **handles
Or perhaps, to allow simple int type too
void union { int num; void *ptr } *handles
Hum, I think I would worry when we have half a dozen back-ends, virConnect content is opaque, allocated/freed only by the library so changing that later won't generate any kind of API or ABI issues. Having explicit pointers at worse may loose a few bytes per connections, and on the other hand having the explicit types there ease debugging. So at this point I think there isn't really to worry about it.
* Connect URIs. The 'virDomainOpen' and 'virDomainOpenReadOnly' methods have an optional parameter 'name'. The Xen drivers currently ignore this, or expect it to be NULL / the string "Xen". For sake of back-compat we'll ned to preserve existing behaviour for NULL, but we should hook up URI parsing for the XenD backend to allow non local connections to work.
yes, that's an area which need refining.
This gives the question of what format should the URI be for Xen domains ? Although 'http://' is the protocol XenD uses, this isn't likely a good idea, because a later VMWare driver might also use a http based protocol. So, perhaps we should use generic URIs:?
xend://somehost:port/
yes I was thinking of somthing like this. The only annoying point is that xend isn't really a protocol i.e. it deviates a bit from URI real semantic and one could think of multiple xend access types (see Anthony's patch for Xend XML-RPC though ssh on xen-devel), but we could do things like xend:///var/run/xend/socket xendssh://user@somehost:port while being relatively clean w.r.t RFC 2396 and Co.
* Driver method hookup. The libvirt.c file has alot of methods which are either not hooked up to the driver backend, or hooked up, but still have duplicated (redundant?) Xen specific calls. Here is the complete status:
Okay, I need to clean them up, please bugzilla this I will fix this soonish.
virGetVersion:
- Hardcodes support for Xen HV. No virConnectPtr handle, so how would we call out to driver backends ?
yes that's an API bug :-\ , I'm afraid that mean I will have to make a release breaking compatibility, annoying, better do that as soon as possible.
virConnectClose:
- Does not call out to driver backends, simply free's struct
okay need to call the virDrvClose if non NULL.
virConnectGetType:
- Does not call out to driver backends, hardcodes Xen HV
Should return the value of virDrvGetType() or the string identifying the driver if NULL
virConnectGetVersion
- Does not call out to driver backends, hardcodes Xen HV
Should return value of virDrvGetVersion()
virConnectListDomains
- Calls out to drivers, but also has duplicated code for XenD & XenStore
Should remove the fallback, that should just work
virConnectNumOfDomains
- Calls out to drivers, but also has duplicated code for XenD & XenStore
same as previous
virDomainLookupByID
- Calls out to drivers, but also has duplicated code for XenD & XenStore
same as previous
virDomainLookupByUUID
- Calls out to drivers, but also has duplicated code for XenD & XenStore
same as previous
virDomainLookupByName
- Calls out to drivers, but also has duplicated code for XenD & XenStore
same as previous
virDomainCreateLinux
- Does not call out to driver backends, hardcodes XenD
that one is a bit complex because that's multistep, but yeah if needed the meat of the routine should just be moved in the xend driver.
virDomainLookupByUUIDString
- OK (but delegates to virDomainLookupByUUID)
virDomainDestroy
- Does not call out to driver backends, hardcodes XenD & Xen HV
bad need fixing to call the driver entry point.
virDomainFree
- Does not call out to driver backends, simply free's struct
same as previous
virDomainSuspend
- Does not call out to driver backends, hardcodes XenD & Xen HV
same as previous
virDomainResume
- Does not call out to driver backends, hardcodes XenD & Xen HV
same as previous
virDomainSave
- Does not call out to driver backends, hardcodes XenD
same as previous
virDomainRestore
- Does not call out to driver backends, hardcodes XenD
same as previous
virDomainShutdown
- Does not call out to driver backends, hardcodes XenD
same as previous
virDomainReboot
- Does not call out to driver backends, hardcodes XenD
same as previous
virDomainGetUUID
- Does not call out to driver backends, hardcodes XenD
virDomainGetName
- OK
virDomainGetUUIDString
- OK (but delegates to virDomainGetUUID)
virDomainGetOSType
- Does not call out to driver backends, calls function in XenStore driver
virDomainGetMaxMemory
- Does not call out to driver backends, hardcodes XenD, Xen HV, XenStore
virDomainGetXMLDesc
- Does not call out to driver backends, hardcodes XenD
Those 3 need to call the corresponding driver entries.
virDomainSetMaxMemory
- OK
virDomainSetMemory
- OK
virDomainGetInfo
- Calls out to drivers, but also has duplicated code for XenD & XenStore
fall back need to be removed
virNodeGetInfo
- OK
virDomainDefineXML
- OK
virDomainUndefineXML
- OK
virDomainListDefinedDomains
- No implemented
virDomainCreate
- No implemented
I need to implement the entry point but I'm waiting on Xend changes to support defined but not running domains.
My immediate needs for testing, are to hook up more of the methods which aren't connected to the driver backends.
Okay I need to clean this up, should not be that hard except the Version API change needed, :-\ maybe I can avoid this by using the version extraction from the first activated driver found. Thanks a lot for going though this ! Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/