[libvirt] [PATCH v8] vepa: parsing for 802.1Qb{g|h} XML

Hugh O. Brock hbrock at redhat.com
Mon May 24 19:35:07 UTC 2010


On Mon, May 24, 2010 at 11:47:18AM -0700, Chris Wright wrote:
> * Daniel P. Berrange (berrange at 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, hbrock at redhat.com, +1-215-564-3232
Deltacloud API + Portal http://deltacloud.org
Libvirt virtualization library http://libvirt.org
========================================================




More information about the libvir-list mailing list