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

Dave Allan dallan at redhat.com
Mon May 24 20:05:18 UTC 2010


On Mon, May 24, 2010 at 03:57:10PM -0400, Stefan Berger wrote:
> On Mon, 2010-05-24 at 15:35 -0400, Hugh O. Brock wrote:
> > 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?
> 
> Could I move
> 
> struct _virVirtualPortProfileDef {
>     enum virVirtualPortType   virtPortType;
>     union {
>         struct {
>             uint8_t       managerID;
>             uint32_t      typeID; // 24 bit valid
>             uint8_t       typeIDVersion;
>             unsigned char instanceID[VIR_UUID_BUFLEN];
>         } virtPort8021Qbg;
>         struct {
>             char          profileID[LIBVIRT_IFLA_VF_PORT_PROFILE_MAX];
>         } virtPort8021Qbh;
>     } u;
> };
> 
> into macvtap.h and still use it in the XML struct for the direct type
> interface?

That seems reasonable from my POV, but I can't speak for Dan, of
course.

Dave




More information about the libvir-list mailing list