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

Daniel Veillard veillard at redhat.com
Thu Jun 26 14:31:49 UTC 2008


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 at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/




More information about the libvir-list mailing list