On Mon, May 24, 2010 at 11:47:18AM -0700, Chris Wright wrote: > * Daniel P. Berrange (berra...@redhat.com) wrote: > > On Sun, May 23, 2010 at 12:51:50PM -0400, Stefan Berger wrote: > > > Index: libvirt-acl/src/util/macvtap.h > > > =================================================================== > > > --- libvirt-acl.orig/src/util/macvtap.h > > > +++ libvirt-acl/src/util/macvtap.h > > > @@ -27,15 +27,14 @@ > > > # if defined(WITH_MACVTAP) > > > > > > # include "internal.h" > > > +# include "conf/domain_conf.h" > > > > This isn't allowed. It is introducing a dependancy cycle > > between the util & conf directories. Code in util/ is not > > allowed to depend on any other code in the libvirt tree. > > IOW, you mean using virDomainNetDefPtr in openMacvtapTap is a libvirt > layering violation, and you'd prefer openMacvtapTap() w/ large number > of parameters? I think it's impractical to not invent some structure to > pass the data...otherwise, I believe the worst case would be: > > int openMacvtapTap(const char *tgifname, > const unsigned char *macaddress, > const char *linkdev, > int mode, > char **res_ifname, > int vnet_hdr, > int vf, > int port_type, > unsigned char mgrid, > unsigned typeid, > const unsigned char *instanceid, > const unsigned char *profileid, > const unsigned char *vmuuid) > > But, any such structure will create some dependency. > > What do you think? > > thanks, > -chris
Earlier today on IRC Dan said: <danpb> if that's really neccessary, a macvtap.h should have its own struct definition, separate from the XML structs. Hopefully that makes sense in this context? --Hugh -- ======================================================== Hugh Brock, hbr...@redhat.com, +1-215-564-3232 Deltacloud API + Portal http://deltacloud.org Libvirt virtualization library http://libvirt.org ======================================================== -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
