<br><tt><font size=2>Daniel Veillard <veillard@redhat.com> wrote
on 04/07/2010 05:22:22 PM:<br>
<br>
<br>
> libvir-list, eblake, berrange</font></tt>
<br><tt><font size=2>> <br>
> Please respond to veillard</font></tt>
<br><tt><font size=2>> <br>
[...]</font></tt>
<br><tt><font size=2>> <br>
>   In general the code looks nice to me, just a few things to
point out<br>
> <br>
> > Index: libvirt-acl/src/nwfilter/nwfilter_learnipaddr.c<br>
> [...]<br>
> > +/* structure of an ARP request/reply message */<br>
> > +struct f_arphdr {<br>
> > +    struct arphdr arphdr;<br>
> > +    uint8_t ar_sha[ETH_ALEN];<br>
> > +    uint32_t ar_sip;<br>
> > +    uint8_t ar_tha[ETH_ALEN];<br>
> > +    uint32_t ar_tip;<br>
> > +} ATTRIBUTE_PACKED;<br>
<br>
> > +<br>
> <br>
>  the 3 structures requiring ATTRIBUTE_PACKED, actually f_arphdr
might be<br>
> the only one really requiring the packing, I don't know how the<br>
> compilers would work withthe 2 * 8 uint8_t arrays of<br>
> ether_vlan_header...</font></tt>
<br>
<br><tt><font size=2>I think most of the compilers should define an equivalent
for __attribute__((packed) just to make structure defined for networking
or hardware easier accessible. #pragma pack(1) might be such a thing, which
then would have to be surrounded with </font></tt>
<br>
<br><tt><font size=2>#if OTHER_COMPILER_THAN_GCC</font></tt>
<br><tt><font size=2># pragma pack(1)</font></tt>
<br><tt><font size=2>#endif</font></tt>
<br>
<br><tt><font size=2>...</font></tt>
<br>
<br><tt><font size=2>#if OTHER_COMPILER_THAN_GCC</font></tt>
<br><tt><font size=2># pragma pop</font></tt>
<br><tt><font size=2>#endif<br>
</font></tt>
<br>
<br><tt><font size=2><br>
> > +checkIf(const char *ifname, const unsigned char *macaddr)<br>
> > +{<br>
> [...]<br>
> >  <br>
> > +int checkIf(const char *ifname, const unsigned char *macaddr);<br>
> > +<br>
> >  #endif<br>
> <br>
>   I think those 3 should really be cleaned up, either merged
with<br>
>   another funcion as suggested, or at least be prefixed to avoid
name<br>
>   pollution. Not extremely urgent especially if there is some
merging<br>
>   with macvtap.c code needed.</font></tt>
<br>
<br><tt><font size=2>Ok. The FIXME would remind me.</font></tt>
<br><tt><font size=2><br>
> <br>
> > Index: libvirt-acl/src/libvirt_private.syms<br>
> > ===================================================================<br>
> > --- libvirt-acl.orig/src/libvirt_private.syms<br>
> > +++ libvirt-acl/src/libvirt_private.syms<br>
> > @@ -488,6 +488,8 @@ virNWFilterRegisterCallbackDriver;<br>
> >  virNWFilterTestUnassignDef;<br>
> >  virNWFilterConfLayerInit;<br>
> >  virNWFilterConfLayerShutdown;<br>
> > +virNWFilterLockFilterUpdates;<br>
> > +virNWFilterUnlockFilterUpdates;<br>
> >  <br>
> >  <br>
> >  #nwfilter_params.h<br>
> > @@ -503,6 +505,16 @@ virNWFilterInstantiateFilter;<br>
> >  virNWFilterTeardownFilter;<br>
> >  <br>
> >  <br>
> > +#nwfilter_learnipaddr.h<br>
> > +ipAddressMap;<br>
> > +ipAddressMapLock;<br>
> > +pendingLearnReq;<br>
> > +pendingLearnReqLock;<br>
> <br>
> as far as I can tell those 4 don't need to be exported as they are
not<br>
> used in any other module, and sine they don't have a virNWFilter prefix<br>
> I think it's cleaner that way. They are actually static in your latest<br>
> version.</font></tt>
<br>
<br><tt><font size=2>Oh, I had some really interesting debugging hours
behind me because there were some weak symbols ('t') in libvirt and it
was linking against another part that was exporting the same symbols ('T').
So the code was there twice if I remember this correctly - been a while.
Sometimes static variables were seen as being initialized, i.e., when access
from code within the nwfilter_learnip.c file and other times when access
from libvirt_conf.c they weren't. Also the static variables all of a sudden
were at two different locations, depending on what the path was that invoked
the code. Crazy. If I remember correctly, some of these entries were the
consequence of this... but now that I checked out the code from git and
ran a test with the 'clean-traffic' filter it may not be the case - at
least I did not see any strange crashes.</font></tt>
<br><tt><font size=2><br>
> <br>
> > +virNWFilterGetIpAddrForIfname;<br>
> > +virNWFilterDelIpAddrForIfname;<br>
> > +virNWFilterLookupLearnReq;<br>
> > +<br>
> > +<br>
> >  # pci.h<br>
> >  pciGetDevice;<br>
> >  pciFreeDevice;<br>
> [...]<br>
> <br>
> > Index: libvirt-acl/configure.ac<br>
> > ===================================================================<br>
> > --- libvirt-acl.orig/configure.ac<br>
> > +++ libvirt-acl/configure.ac<br>
> > @@ -41,6 +41,7 @@ XMLRPC_REQUIRED=1.14.0<br>
> >  HAL_REQUIRED=0.5.0<br>
> >  DEVMAPPER_REQUIRED=1.0.0<br>
> >  LIBCURL_REQUIRED="7.18.0"<br>
> > +LIBPCAP_REQUIRED="1.0.0"<br>
> >  <br>
> >  dnl Checks for C compiler.<br>
> >  AC_PROG_CC<br>
> > @@ -1045,6 +1046,39 @@ AC_SUBST([NUMACTL_CFLAGS])<br>
> >  AC_SUBST([NUMACTL_LIBS])<br>
> >  <br>
> >  <br>
> > +dnl pcap lib<br>
> > +LIBPCAP_CONFIG="pcap-config"<br>
> > +LIBPCAP_CFLAGS=""<br>
> > +LIBPCAP_LIBS=""<br>
> > +LIBPCAP_FOUND="no"<br>
> > +<br>
> > +AC_ARG_WITH([libpcap], AC_HELP_STRING([--with-libpcap=@<:@PFX@:>@],<br>
> > [libpcap location]))<br>
> > +if test "$with_qemu" = "yes"; then<br>
> > +    if test "x$with_libpcap" != "xno"
; then<br>
> <br>
> Somehow we are binding this completely to the compilation of qemu,<br>
> in the detection and in the spec file, it's fine for now but maybe<br>
> should be relaxed at some point.</font></tt>
<br>
<br><tt><font size=2>Currently it only works for Qemu...</font></tt>
<br>
<br><tt><font size=2>Great that the code is 'in'.</font></tt>
<br>
<br><tt><font size=2>Thanks.</font></tt>
<br>
<br><tt><font size=2>   Stefan</font></tt>
<br>