Re: virDomainInfo marshalling prolem

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

 



ïThere is an unmanaged type to specify when marshaling this : UnamanagedType.SysInt or UnmanagedType.SysUInt, which are 64b or 32bits aware. But the problem under windows : libvirt is compiled thru mingwin so the dll is in 32bits and even if windows is in 64bits, I have to make bindings over 32bits (I'm not sure my english make things clear when I explain)

Arnaud

--------------------------------------------------
From: <arnaud.champion@xxxxxxxxxx>
Sent: Friday, October 29, 2010 4:41 PM
To: "Matthias Bolte" <matthias.bolte@xxxxxxxxxxxxxx>; "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Cc: <libvir-list@xxxxxxxxxx>
Subject: Re:  virDomainInfo marshalling prolem

Mouarf, funny thing :)


--------------------------------------------------
From: "Matthias Bolte" <matthias.bolte@xxxxxxxxxxxxxx>
Sent: Friday, October 29, 2010 4:36 PM
To: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Cc: <arnaud.champion@xxxxxxxxxx>; <libvir-list@xxxxxxxxxx>
Subject: Re:  virDomainInfo marshalling prolem

2010/10/29 Daniel P. Berrange <berrange@xxxxxxxxxx>:
On Fri, Oct 29, 2010 at 04:19:22PM +0200, Matthias Bolte wrote:
2010/10/29  <arnaud.champion@xxxxxxxxxx>:
> 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]