Daniel P. Berrange wrote:
Historically NULL == 'Xen', so should we just force 'name = Xen' in src/libvirt.c
and then no internal driver ever has to worry about NULLs in this scenario again.
Is the plan not to have NULL meaning "get me the most appropriate
connection", sort of in the same way that XOpenDisplay (NULL) works?
OTOH I have no idea how to realise such a plan (but that's a completely
separate issue).
struct remote_domain_lookup_by_id_ret {
/* XXX "Not found" semantic is ill-defined. */
remote_nonnull_domain dom;
};
struct remote_domain_lookup_by_uuid_ret {
/* XXX "Not found" semantic is ill-defined. */
remote_nonnull_domain dom;
};
struct remote_domain_lookup_by_name_ret {
/* XXX "Not found" semantic is ill-defined. */
remote_nonnull_domain dom;
};
We should remember to formally define the semantics before release :-)
So at the moment both Not found and Error conditions turn into
virterrors, which was the point of my comment. As far as I can see the
way out of this is either to add another call which has better
semantics, such as:
int virDomainLookupByID2 (virConnect Ptr conn,
int id, virDomainPtr *domain_out);
or else to define a special virterror for the Not found case. The
latter is obviously more compatible and doesn't require extra
interfaces. In any case, this is a separate issue from the remote patch.
struct remote_domain_get_info_ret {
unsigned char state;
unsigned hyper max_mem;
unsigned hyper memory;
unsigned short nr_virt_cpu;
/* XXX cpu_time is declared as unsigned long long */
unsigned hyper cpu_time;
};
hyper == 64-bits according to the latest XDR spec isn't it. The
only guarentee we need is that cpu_time is at least 64-bits. Given
the granularity we should never hit a scenario where cpu_time would
overflow 64-bits. So if long long ever happens to be 128, then it
shouldn't matter that hyper were only 64. So I reckon we can remove
the XXX there.
Yes hyper is 64 bits (always). I'll remove the XXX.
Rich.