Re: [libvirt] PATCH: Generic internal API for domain XML parser/formatter

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.

> 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