Tóth István wrote:
Thanks for the replaysIf 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
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.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 theremote access would have made the Java bindings more platform independantbut I had troubles with the RPC/TLS support, and didn't go very far. Maybea JNI based solution is good enough for most potential Java users.
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
smime.p7s
Description: S/MIME Cryptographic Signature
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
