Re: [Libvir] Documentation errors and shortcomings
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
Attachments:
- smime.p7s (application/x-pkcs7-signature — 3.2 KB)