[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [libvirt] [PATCH v8] vepa: parsing for 802.1Qb{g|h} XML
- From: Stefan Berger <stefanb linux vnet ibm com>
- To: "Hugh O. Brock" <hbrock redhat com>
- Cc: Chris Wright <chrisw redhat com>, libvir-list <libvir-list redhat com>, gerhard stenzel de ibm com
- Subject: Re: [libvirt] [PATCH v8] vepa: parsing for 802.1Qb{g|h} XML
- Date: Mon, 24 May 2010 15:57:10 -0400
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 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?
Stefan
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]