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 :|