On Wed, Jul 11, 2007 at 02:11:38PM +0200, Christian Ehrhardt wrote:
That would be perfect ! Maybe we don't even need to hook in configure I'm sure endianness info can come from standard headers, then combined with a processor check that should be sufficient I guess.
Without introducing all the guest handle infrastructure and by just fixing the known xen_v2s3_getdomaininfolistop and xen_v2d5_cpumap the patch became as nice and small as a patch should be ;-)
yup, see it suddenly becomes quite small :-) maybe a tad bit too small though
The Libvirt padding is now handled by using gcc's __BIG_ENDIAN__, no configure/header/... needed that way. I think we can assume that at least when libvirt is compiled for ppc gcc is used right?
yes the only potential problem would be with other architectures where __BIG_ENDIAN__ is defined and where the relative size of pointers and long would be different.
I used one (1) really generic line from our ppc libxc code, this should be no licencing issue (LGPL vs. GPL). Tell me if someone think otherwise and I'll try to change it a bit.
No I guess it's generic enough :-)
Since it is no longer a macro we could pre-calculate the sizes anyway, but the way it is now says clearly "64bit size - used size" for the padding and I like that kind of readability.
Yes this makes for very long line, but it's really not a concern. I'm tempted to apply that patch after a day of grace delay to give people a chance to voice in ! thanks a lot ! Does this fix all the libvirt proper platform issues (i.e. independantly of possible xen specific ones) ? Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/