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

[Daniel P. Berrange]

On Sat, May 05, 2007 at 11:53:32AM +0100, Richard W.M. Jones wrote:
> Richard W.M. Jones wrote:
> >2 Client-server protocol
> >------------------------
> >
> >A qemud/remote_protocol.x
> >A qemud/rpcgen_fix.pl
> >A qemud/remote_protocol.c
> >A qemud/remote_protocol.h
> 
> These are the additional files required to describe the XDR-based 
> protocol for client-server communications, with the homebrew RPC 
> mechanism on top.  The first file is the protocol itself.
> 
> The second file is a Perl script to run after rpcgen which allows the 
> code to compile with -Wall -Werror -fstrict-aliasing, and fixes a 64 bit 
> bug (that fix really should go upstream BTW).  The strict-aliasing issue 
> isn't fully fixed yet - I expect that eventually we should compile 
> remote_protocol.c with -fno-strict-aliasing, for safety.  Daniel 
> Veillard also asked that this be rewritten in Python (pah!) which I 
> might do at the same time.
> 
> The last two files are the actual rpcgen-generated rpcgen_fix-fixed 
> code.  I put these two files into EXTRA_DIST because I feel that people 
> shouldn't be required to have rpcgen & Perl just to compile libvirt. 
> (These files are arch-independent so there is no need to recompile them 
> unless remote_protocol.x itself changes).

While I generally don't like having auto-generated files in CVS, I wonder
if this makes us better off for portability to Solaris / BSD. eg, the
Perl post-processor probably wouldn't work with someone else's rpcgen
output. As long as the generated files are calling 100% public RPC related
APIs internally we're probably best off distributing the generated files
as part of the release & only manually doing re-generation when we have
real changes.

> struct remote_open_args {
>     /* NB. "name" might be NULL although in practice you can't
>      * yet do that using the remote_internal driver.
>      */
>     remote_string name;
>     int flags;
> };

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.

> struct remote_get_max_vcpus_args {
>     /* The only backend which supports this call is Xen HV, and
>      * there the type is ignored so it could be NULL.
>      */
>     remote_string type;
> };

Good point. I'll implement this API for QEMU real soon now....

> 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 :-)

> 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.

> struct remote_network_lookup_by_uuid_ret {
>     /* XXX "Not found" semantic is ill-defined. */
>     remote_nonnull_network net;
> };
> 
> struct remote_network_lookup_by_name_ret {
>     /* XXX "Not found" semantic is ill-defined. */
>     remote_nonnull_network net;
> };

As above.

> const REMOTE_PROGRAM = 0x20008086;

Any significance to this number :-)

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|