[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libguestfs] [PATCH 2/2] Use an internal representation of domain metadata

On Tue, Mar 15, 2011 at 01:32:06PM +0000, Matthew Booth wrote:
> On 15/03/11 11:47, Richard W.M. Jones wrote:
> >On Fri, Mar 11, 2011 at 01:34:48PM +0000, Matthew Booth wrote:
> >[...]
> >
> >You seem to be convinced this is better, and I'm not going to argue
> >with that, so ACK to the patch in general.
> >
> >I have specific comments on the fields you are (not) preserving below.
> >
> >>+%
> >>+  name          The name of the domain
> >
> >I think you need to include the /domain/description free text field
> >here too.
> >
> >Also /domain/uuid seems pretty important.
> Ok.
> >Is there nothing /domain/os which is important?  How about
> >/domain/os/sysinfo (SMBIOS information).
> For more esoteric stuff like this, I would prefer to wait until it's
> actually shown to be a problem in practise.
> >>+  memory        The memory assigned to the domain, in bytes
> >
> >I'm assuming that virt-v2v no longer runs on 32 bit architectures (or
> >else sizes in bytes tend to get converted to floats and rounded
> >awkwardly).  Is there a check for this, like the one in virt-resize?
> >
> >http://git.annexia.org/?p=libguestfs.git;a=blob;f=tools/virt-resize;h=4beb45b57df315e551ecb4be8b3748e2a565eeb0;hb=HEAD#l33
> Nice. I hadn't actually considered this at all. Is there any way to
> make perl do 64-bit integers?

Sort of. At the Perl layer you want them to be just stored as strings,
instead of perl integers which may well only be 32bit, *even* on 64-bit

In Sys::Virt and Net::DBus I do this (which was inspired from GLib

  #ifndef PRId64
  #define PRId64 "lld"

  SV *
  virt_newSVll(long long val) {
  #ifdef USE_64_BIT_ALL
    return newSViv(val);
    char buf[100];
    int len;
    len = snprintf(buf, 100, "%" PRId64, val);
    return newSVpv(buf, len);

  long long
  virt_SvIVll(SV *sv) {
  #ifdef USE_64_BIT_ALL
    return SvIV(sv);
    return strtoll(SvPV_nolen(sv), NULL, 10);

And likewise another pair of functions for 'unsigned long long'.

In terms of usage, putting a long long into a hash:

      (void)hv_store (RETVAL, "rx_bytes", 8, virt_newSVll(stats.rx_bytes), 0);

Or getting a long long from Perl SV*

      long long v = virt_SvIVll(*val);

This doesn't fully solve the problem, because if you want todo
arithmetic on the values once in the Perl code, you can't cast
the strings straight back to ints without loosing data. But you
can put them into one of the CPAN  BigInt/BigMath modules and
use them. The key goal is to just not loose data in the XS<->Perl
interface layer, to allow the Perl layer options in how to deal
with the problem.

|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]