I've defined (among others): int esxVI_PhysicalNic_CastListFromAnyType(virConnectPtr conn, esxVI_AnyType *anyType, esxVI_PhysicalNic **pNicList); but runing it returns somthing like: Expecting type 'PhysicalNic' but found 'ArrayOfPhysicalNic'
Does it mean I should also implement: esxVI_ArrayOfPhysicalNic_CastListFromAnyType() and all the funcs/type definition coming with it? thanks Shahar ________________________________ From: Matthias Bolte <matthias.bo...@googlemail.com> To: Shahar Klein <shaharkl...@yahoo.com> Cc: libvir-list@redhat.com Sent: Thursday, September 10, 2009 6:24:25 PM Subject: Re: [libvirt] Interface driver and ESX support 2009/9/10 Shahar Klein <shaharkl...@yahoo.com>: > I'm not sure what you mean about mapping > lets take the pnics as a study case for me > do I need to define a structure similar to this: > http://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/vim.host.PhysicalNic.html > and also take care for it's allocation? > Yes, you need to implement the mapping (a better word may be 'binding') of this VI API type to a C type, that also includes to care about its allocation. You'll need to implement at least this set of function in esx_vi_types.[ch]: esxVI_PhysicalNic_Alloc() esxVI_PhysicalNic_Free() esxVI_PhysicalNic_CastFromAnyType() esxVI_PhysicalNic_CastListFromAnyType() esxVI_PhysicalNic_Deserialize() esxVI_PhysicalNic_DeserializeList() You could use the binding for the HostCpuIdInfo type, but unfortunately I haven't published the code for it yet. This code also includes some essential helper functions for esxVI_PhysicalNic_CastListFromAnyType(). Beside the PhysicalNic type, you may also have to bind the types of its members like PhysicalNicLinkInfo, PhysicalNicSpec and HostIpConfig, if you need or care about the information provided by them. The binding for HostCpuIdInfo is part of a larger set of patches that add some new features to ESX driver, but the patches needs some cleanup first. I may have some time later this evening to clean them up and post them. PS: You should refer to version 2.5 of the VI API [1] and not 4.0, because the complete VI API mapping is currently based on version 2.5. At some point I'll have to properly distinguish between version 2.5 and 4.0, but currently I would like to stick to version 2.5 only. [1] http://www.vmware.com/support/developer/vc-sdk/visdk25pubs/ReferenceGuide/ Matthias
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list