_read and _write. Fix gather to not return the string 'None' when reading a
value of type string that does not exist. The value None should be returned
instead.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
parameters between functions in the base classes and those that override them
in subclasses. It's hard to see how this code worked at all.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
previously. This would have caused a memory leak when attempting to get info
on a domain that does not exist.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
underlying xc_domain_setmaxmem already took an unsigned int, and
PyArg_ParseTupleAndKeywords call was only parsing an int, so there is no way
that longer values would get through here in any case. Fixing the documentation
and the local variable is the best solution, until someone decides that we need
to support maxmem values greater than 2TiB.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
xs_write with O_CREAT|O_EXCL causes problems over daemon restarts, since
it's not idempotent.
It turns out noone really needs the flags word at all, so get rid of it.
It's now as if everyone specified "O_CREAT".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
Also don't add XendDomainInfo object to XendDomain dictionary from
XendDomainInfo object but do it in XendDomain.
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
Renamed variables type and ord since these clash with built-in names. Renamed
unused variables to mark them as such. Changed scheduler.py to use *args and
**kwargs rather than the strange non-idiomatic imitation of the same.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
configure_maxmem method. The config_handlers mechanism was trying to be a
general configuration-registration framework, but that functionality was
unused and confusing.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
this looks like the resurrection of DevController from controller.py, but the
mechanism is actually very different. Device handling is now stateless inside
xend, relying on the store for state management, reducing DevController
instances to one-shot lifetimes. Dev and its subclasses have gone completely.
The device creation code itself has moved from XendDomainInfo.createDevice into
DevController subclasses, and the previous contents of the subclasses has been
discarded (these subclasses were no longer being called, so all this code was
dead).
XendDomainInfo.getDeviceIds has gone, as it was unused.
XendDomainInfo.delete_device has been subsumed by XendDomainInfo.destroyDevice;
since device handling is now stateless inside xend, the distinction between
device 'deletion' and device 'destruction' is meaningless.
The s-expression describing devices has gone, as this information is no longer
available to xend in the same way, and seems to be unused. If it is required,
it can be reinstated by loading device information from Xen or the store.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
handling exceptions raised inside that transaction. If the creation (start) of
the transaction fails, then t has not been assigned, and in any case no
transaction has been created, so it is wrong to attempt to abort that
(non-existent) transaction.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
setStoreChannel was only ever called with channel=None (implying that the
current channel would be closed) so the other code there was superfluous.
Signed-off-by: Ewan Mellor<ewan@xensource.com>
getTargetMemory inside image.py to decouple the latter from the internals of
the former. Move the definition of xc inside image.py to please pylint.
Signed-off-by: Ewan Mellor<ewan@xensource.com>
getDomain, getName in SrvDomainDir, to decouple the latter from the internals of
the former, in preparation for changes internal to XendDomainInfo.
Signed-off-by: Ewan Mellor<ewan@xensource.com>
parameters in our code. Removed map and filter from bad-functions - I don't
think that we have any problem with functional programming styles!
Signed-off-by: Ewan Mellor<ewan@xensource.com>
Directly modifying the sysfs entries causes the xenstore state of
a cpu's availability to be incorrect. Also slightly modify the
dom0-cpus description in the xend-config. Rather than specifying which
dom0 vcpus are to be used, it is now a target of how many vcpus to use
as pinvcpu ops are the preferred method for setting which physical cpu a
vcpu uses.
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
emellor@ewan
cl349@firebug.cl.cam.ac.uk