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(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/