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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list