Hi, This patch intends to run libvirt 0.2.0 on IA64. Signed-off-by: Atsushi SAKAI <sakaia(a)jp.fujitsu.com&gt;

Just one question, is there any plan to support big/little endian for libvirt? (related to network)

Hi, Dan Thank you for your comments. 1) This patch is for rpmbuild failure on IA64. see the attached log (it is stopped in conf.c compilation) 2) About above fixes code.(endian issue) Sorry for short discripting this issue. My point is you are casting (unsigned int*) for unsigned char. In little endian, this works fine?$B!!(conf.c). But big endian case, this inputs "00" for character value.

conf.c: In function 'qemudParseInterfaceXML': conf.c:450: warning: cast increases required alignment of target type conf.c:451: warning: cast increases required alignment of target type conf.c:452: warning: cast increases required alignment of target type conf.c:453: warning: cast increases required alignment of target type conf.c:454: warning: cast increases required alignment of target type conf.c:455: warning: cast increases required alignment of target type make[2]: *** [libvirt_qemud-conf.o] Error 1 make[2]: Leaving directory `/home/sakaia/rpmbuild/BUILD/libvirt-0.2.0/qemud' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/sakaia/rpmbuild/BUILD/libvirt-0.2.0' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.48812 (%build)

- ((struct sockaddr_in *)&ifr.ifr_addr)->sin_family = AF_INET; - ((struct sockaddr_in *)&ifr.ifr_addr)->sin_addr = inaddr; + ((struct sockaddr_in *)((void *)&ifr.ifr_addr))->sin_family = AF_INET; + ((struct sockaddr_in *)((void *)&ifr.ifr_addr))->sin_addr = inaddr;

> > - ((struct sockaddr_in *)&ifr.ifr_addr)->sin_family = AF_INET; > > - ((struct sockaddr_in *)&ifr.ifr_addr)->sin_addr = inaddr; > > + ((struct sockaddr_in *)((void *)&ifr.ifr_addr))->sin_family = AF_INET; > > + ((struct sockaddr_in *)((void *)&ifr.ifr_addr))->sin_addr = inaddr;

bridge.c: In function 'brSetInetAddr': bridge.c:344: warning: cast increases required alignment of target type bridge.c:345: warning: cast increases required alignment of target type bridge.c: In function 'brGetInetAddr': bridge.c:381: warning: cast increases required alignment of target type

Hi, Mark Thank you for your suggestion. I just compiled it sucessfuly. It should be work. I will do test it tomorrow. Thanks Atsushi　SAKAI Mark McLoughlin <markmc(a)redhat.com&gt; wrote: > Hi, > Thanks for that ... > > On Tue, 2007-02-20 at 13:51 +0900, Atsushi SAKAI wrote: > > > > > - ((struct sockaddr_in *)&ifr.ifr_addr)->sin_family = AF_INET; > > > > - ((struct sockaddr_in *)&ifr.ifr_addr)->sin_addr = inaddr; > > > > + ((struct sockaddr_in *)((void *)&ifr.ifr_addr))->sin_family = AF_INET; > > > > + ((struct sockaddr_in *)((void *)&ifr.ifr_addr))->sin_addr = inaddr; > > > bridge.c: In function 'brSetInetAddr': > > bridge.c:344: warning: cast increases required alignment of target type > > bridge.c:345: warning: cast increases required alignment of target type > > bridge.c: In function 'brGetInetAddr': > > bridge.c:381: warning: cast increases required alignment of target type > > Okay, my understanding of this is that: > > - The warning is caused by -Wcast-align > > - Our problem is that we're casting between pointers to struct > sockaddr and struct sockaddr_in, which look like > > struct sockaddr > { > unsigned short int sa_family; > }; > > struct sockaddr_in > { > unsigned short int sin_family; > uint16_t sin_port; > struct { uint32_t s_addr } sin_addr; > }; > > - Because of the uint32_t, struct sockaddr_in is required to be > aligned to a 4 byte boundary, whereas on ia64 struct sockaddr is > only required to be aligned to a 2 byte boundary > > - If we look at in the context of struct ifreq, though: > > struct ifreq > { > .... > union { > struct sockaddr ifru_addr; > .... > void *ifru_data; > } ifr_ifru; > }; > #define ifr_addr ifr_ifru.ifru_addr > #define ifr_data ifr_ifru.ifru_data > > we see that because of the void pointer in the union, the struct > sockaddr is actually guaranteed to be aligned to 8 bytes and so the > warning can be ignored. > > - I'd prefer to avoid the void pointer cast as someone could come > along and wonder whether the cast is hiding a genuine problem. > > - So, I think I'll go ahead and do it this way instead: > > - ((struct sockaddr_in *)&ifr.ifr_addr)->sin_family = AF_INET; > - ((struct sockaddr_in *)&ifr.ifr_addr)->sin_addr = inaddr; > + ((struct sockaddr_in *)&ifr.ifr_data)->sin_family = AF_INET; > + ((struct sockaddr_in *)&ifr.ifr_data)->sin_addr = inaddr; > > Cheers, > Mark. > -- Libvir-list mailing list Libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list