* Stefan Berger (stefanb@xxxxxxxxxx) wrote: > Daniel Veillard <veillard@xxxxxxxxxx> wrote on 05/11/2010 06:07:58 AM: > > > > > > On Mon, May 10, 2010 at 07:57:37PM -0400, Stefan Berger wrote: > > > Below is David Alan's original patch with lots of changes. > > > > > > In particular, it now parses the following XML and stored the data > > > internally. No sending of netlink messages has been implemented here. > > > > > > <interface type='direct'> > > > <source dev='static' mode='vepa'/> > > > <model type='virtio'/> > > > <vsi managerid='12' typeid='0x123456' typeidversion='1' > > > instanceid='fa9b7fff-b0a0-4893-8e0e-beef4ff18f8f' /> > > > <filterref filter='clean-traffic'/> > > > </interface> > > > > > > <interface type='direct'> > > > <source dev='static' mode='vepa'/> > > > <model type='virtio'/> > > > <vsi profileid='my_profile'/> > > > </interface> > > > > > > I'd suggest to use this patch as a base for sending out netlink > > > messages. > > > > > > Signed-off-by: Stefan Berger <stefanb@xxxxxxxxxx> > > > > I have 2 basic questions: > > > > - how can we be sure that if we apply this the XML interface won't > > need to change due to kernel interfaces, maybe Chris can confirm > > that the kernel is now stable enough that this should not affect > > the XML anymore > > I have been trying to gather the parameters necessary to trigger the > slightly > different setup protocols. I cannot be sure that this XML won't change at > the > moment but would also wait to have it checked in. However, the parser here > works to the best of my current knowledge. > The netlink messages that require these parameters drive the requirements > to the XML. So, I'd wait for the kernel implementation to become stable. > > > > - can I get some signoff from Cisco that there is agreement on this > > format and that will be sufficient for their need > > I'd also like to have 100% re-assurance that the TWO pre-standards we are > dealing > with here are not going change later on and cause changes affecting the > XML. Honestly, the only way you'll get that is to wait until they are standards (and even then there's possible changes, additions, etc). The low-level TLVs and the protocol ladder diagrams are not under substantial churn. Names change regularly, but the notion of preassociate/associate/deassociate and the basic id's for VDP payload (database id, profile id, mac+vlan pairs, etc). thanks, -chris -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list