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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/