Re: [libvirt] virDomainInfo marshalling prolem

Mouarf, funny thing :) -------------------------------------------------- From: "Matthias Bolte" <matthias.bolte(a)googlemail.com&gt; Sent: Friday, October 29, 2010 4:36 PM To: "Daniel P. Berrange" <berrange(a)redhat.com&gt; Cc: <arnaud.champion(a)devatom.fr>; <libvir-list(a)redhat.com&gt; Subject: Re: [libvirt] virDomainInfo marshalling prolem > 2010/10/29 Daniel P. Berrange <berrange(a)redhat.com&gt;: >> On Fri, Oct 29, 2010 at 04:19:22PM +0200, Matthias Bolte wrote: >>> 2010/10/29 <arnaud.champion(a)devatom.fr&gt;: >>> > Hi, >>> > >>> > I am working on the marshaling of the virDomainInfo structure. I have >>> > marshalled it in this way : >>> > >>> > >>> > /// >>> > >>> > <summary> >>> > >>> > /// Structure to handle domain informations >>> > >>> > /// </summary> >>> > >>> > [ >>> > >>> > StructLayout(LayoutKind.Sequential)] >>> > >>> > public class DomainInfo >>> > >>> > { >>> > >>> > /// <summary> >>> > /// The running state, one of virDomainState. >>> > /// </summary> >>> > private Byte state; >>> > /// <summary> >>> > /// The maximum memory in KBytes allowed. >>> > /// </summary> >>> > public int maxMem; >>> > /// <summary> >>> > /// The memory in KBytes used by the domain. >>> > /// </summary> >>> > public int memory; >>> > /// <summary> >>> > /// The number of virtual CPUs for the domain. >>> > /// </summary> >>> > public short nrVirtCpu; >>> > /// <summary> >>> > /// The CPU time used in nanoseconds. >>> > /// </summary> >>> > public long cpuTime; >>> > /// <summary> >>> > /// The running state, one of virDomainState. >>> > /// </summary> >>> > public DomainState State { get { return (DomainState)state; } } >>> > >>> > } >>> > >>> > It work fine in 32 bits, but not in 64 bits, it seems that packing in >>> > 64 >>> > bits is different so infos are not in order. Am I right ? >>> > >>> >>> In the struct looks like this >>> >>> struct _virDomainInfo { >>> unsigned char state; /* the running state, one of >>> virDomainState */ >>> unsigned long maxMem; /* the maximum memory in KBytes allowed >>> */ >>> unsigned long memory; /* the memory in KBytes used by the >>> domain */ >>> unsigned short nrVirtCpu; /* the number of virtual CPUs for the >>> domain */ >>> unsigned long long cpuTime; /* the CPU time used in nanoseconds */ >>> }; >>> >>> but you mapped unsigned long to int. First of all you should map this >>> to an unsigned type. You also lost the unsigned for some other >>> members. >>> >>> The problem probably is that long in C is 32bit on a 32bit platform an >>> 64bit on a 64bit platform. You mapped it to int that is always 32bit >>> in C#, when I looked it up correctly. >> >> Not quite. Windows just had to do things diffrently on 64-bit and so >> used >> the LLP64 model instead of LP64 used by the rest of the world :-( >> >> http://technet.microsoft.com/en-us/library/bb496995.aspx >> >> In the UNIX/64 data model: >> The size of int is 32 bits and the size of long and pointers is 64 >> bits. >> >> In the Win64 model: >> The size of int and long is 32 bits; the size of int64 (new type) >> and pointers is 64 bits. >> >> Regards, >> Daniel >> > > Ah yes. I forgot about that one. So this gets even more complicated > when you want to get the C# bindings working on 32 and 64 bit Windows > and Linux. > > Matthias > -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list