[Libvir] Documentation errors and shortcomings

[Richard W.M. Jones]

Tóth István wrote:
> Thanks for the replays
> 
>> If an individual stats field isn't supported by the hypervisor, it 
>> will be returned as ((long long) -1) [for various reasons we're using 
>> long long here, but really we mean 64 bit signed int].
> Thats very useful info, I spent quite a lot of time messing with 
> BigIntegers, because I didn't want to loose the top bit.
> 
> By the way, there are quite a few unisgned ints, and unsigned longs in 
> the API.
> Am I right to assume that "unsigned int" is 32 bits, so It will only fit 
> into a java long, and "unsigned long" is 64 bits, so it won't fit safely 
> in any java primitive variable? (Apart form the stats members, as you 
> wrote above)

It's very much on a case-by-case basis, unfortunately.

For example you're very unlikely to have problems with the signed nature 
of Java's 64 bit integers when dealing with stats.  Even though the 
stats are cumulative you wouldn't see a discrepency until the guest had 
transferred over 8.5 exabytes of network or block data.  On a 10 gigE 
card operating at full speed that would take 272 years -- even assuming 
a Xen guest could fill the bandwidth of 10 gigE, which is a joke.

Similar considerations apply to "unsigned long maxMem" (in Kilobytes, so 
that the overflows start to occur at 2048 GB) and so on.  That's one we 
might actually hit in a few years, although it'll be equally a problem 
for C callers and for Java callers so we'll have to extend the API when 
it happens.

In fact I can't see a use of unsigned which is a cause for concern, and 
in the OCaml bindings I map these quantities into signed 32- and 64-bit 
integers.

For the reasoning behind long long vs stdint.h, see: 
https://www.redhat.com/archives/libvir-list/2007-August/msg00096.html

>> Interesting, so you're using JNI direct access to the C library, right ?
>> I looked at this a few weeks ago, but it was looking like accessing 
>> using the
>> remote access would have made the Java bindings more platform independant
>> but I had troubles with the RPC/TLS support, and didn't go very far. 
>> Maybe
>> a JNI based solution is good enough for most potential Java users.
> I thought about that too, but then I read the stern warnings about not 
> using the private on-the-wire protocol, so I settled on JNI.
> I think getting all the crypto and protocol stuff right would be more 
> work than the JNI version, anyway. Of course since most people won't 
> want to run the JVM as root, having to use a network URI is almost 
> required through JNI, too.

Yes, avoid talking the remote protocol.

> Also, I have found an other possible problem in the API/documentation:
> The Enum virDomainRestart is defined, but it is not referenced anywhere. 
> Is it the flag parameter to reboot?

I strongly suspect that is a bug actually.

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070911/a2de1e58/attachment-0001.bin>