On Thu, Jun 26, 2008 at 02:53:44PM +0100, Daniel P. Berrange wrote: > On Thu, Jun 26, 2008 at 09:19:15AM -0400, Daniel Veillard wrote: > > On Tue, Jun 24, 2008 at 04:34:11PM +0100, Daniel P. Berrange wrote: > > > We currently have five drivers which handle the domain XML containing > > > duplicated parsers and formatters for the XML with varying degrees of > > > buginess, and often very similar structs. This patch introduces a new > > > general purpose internal API for parsing and formatting network XML, > > > and representing it as a series of structs. > > > > Okay, very good, +1 on principle > > > > > This code is derived from the current equivalent code in the QEMU driver > > > for domains, but with alot of extra config parsing added for stuff needed > > > by the Xen drivers. I have not yet added the extra bits needed by the > > > container based drivers, LXC and OpenVZ, but don't anticipate any problems > > > in this regard. > > > > The question is how much the data structure will need to grow to cover > > new hypervisor cases, the understainties on the set of data was one of > > the primary reasons of an XML only API, ultimately we may be able to > > bet with a fixed set and include it in the API with ABI guarantees. Still > > a bit premature IMHO but something we need to keep in mind for long term. > > Those datastructures are in my opinion what will allow us to declare > > victory in the end and push a 1.0.0 release at some point. > > The data structures will definitely change / extend for container based > virt. We'll also add new device types, eg PCI / USB device passthrough. > I expect we'll get more attributes in various places too. > > So to make this ABI safe would be quite tricky. I'd want to see us have > fully functional OpenVZ, LXC and VMWare drivers before we considered > claiming the structs were at all stable, since they're significantly > different in comparison to Xen & KVM which are really very similar. oh, sure, it's clearly not a short term goal :-) > > hum, maybe it's a good idea to keep that flag generic with secure being just > > one bit. Maybe things like difference between runtime and defined versions > > will need to be provided there as an example too. > > One of the flags from the public API gets dealt with at a higher level > in the impls, so that just left the security flag. We may add more flags > later though, so I'll make this generic & just mask off the bits we deal > with elsewhere okay, thanks, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list