Re: virDomainInfo marshalling prolem

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

 



On Fri, Oct 29, 2010 at 03:30:08PM +0100, Daniel P. Berrange wrote:
> 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.


NB, while this means that int, long and long long don't vary in size between
on Win32 and Win64, I bet that compiler alignment in structs will be 8 bytes
for Win64, and only 4 bytes for Win32. So while the above C# struct definition
may be correct in terms of its types, the alignment of fields is possibly
wrong for 64 bit.

Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
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]