On Thu, Apr 09, 2009 at 11:11:07AM -0400, Cole Robinson wrote: > I suppose it depends on the definition of 'live' here, since currently > with the test driver we do go through the same XML parsing routines that > the 'live' drivers use (that's how I interpreted David's intentions > anyways). Obviously we don't want to be mucking with actual network > interfaces, but if we can use netcf to parse XML, that saves code > duplication, and tests relevant 'live' code. > > Just for my own clarification, is the interface driver _actually_ going > to duplicate the XML parsing/building of netcf? I assumed we were just > going to do a wholesale passthrough to netcf in that case. That sounds > like the best thing to do to just get this up and running. If we need to > in the future, we could always just fork off our own subset of the netcf > format and implement our own parser. But it doesn't sound like it gains > us much doing it up front. There should be XML parsing & formatting routines in libvirt because not everything is going to use netcf, and the test driver shouldn't depend on it. Even for drivers using netcf, libvirt will also have to potentially augment info returned from netcf. For example, with interfaces that are online, libvirt needs to include information about the IPv4/6 addresses obtained by DHCP / IPv6 autoconfig, and potentially more ops that are not related to configuration. Looking at the VirtualBox API, I see it provides a full set of RPC APIs for dealing with physical interface config, so that will need the XML parsing APIs in libvirt too. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list