On Mon, Apr 30, 2007 at 06:48:26PM +0100, Richard W.M. Jones wrote:
> Richard W.M. Jones wrote:
> >The only problem area are the upper limits imposed on the lengths of
> >various strings and arrays. The upper limits seem to be required for
> >safely decoding messages from untrusted sources. Some of them however
> >would impose limits on such things as the number of CPUs supported,
> and also on number of domains.
>
> >/* For each call we may have a 'remote_CALL_args' and 'remote_CALL_ret'
> > * type. These are omitted when they are NULL.
>
> Instead of "NULL" that should read "void".
>
> >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;
> >};
>
> AFAICS the 'type' parameter to GetMaxVcpus is never used.
We never implemeneted this API for QEMU - when we do, then this parameter will
be used.
> >struct remote_domain_lookup_by_name_ret {
> > /* XXX "Not found" semantic is ill-defined. */
> > remote_nonnull_domain dom;
> >};
>
> There are various of these FooLookupByBar functions and as far as I can
> see no one has given much thought to a semantic for "Not found" which
> differs from some other error. Am I missing something?
>
>
> >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;
> >};
>
> It wasn't clear if cpu_time, defined as unsigned long long in C, could
> be larger than 64 bits. XDR supports 64 bits max, so if it is larger
> we'd need to send _hi and _lo hypers.
AFAIK all current 64-bit platforms define long long as 64-bits. In terms
of the data we're actually representing here - the total CPU time accumulated
to a guest, 64 bits is plenty of space. So even if it were 128-bit, we'd
never have more than 64-bits worth of data stored, so we'd be able to safely
drop the high 64-bits.
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 -=|