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