[Libvir] [PATCH] Remote 2/8: Client-server protocol (updated)

[Richard W.M. Jones]

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.