[Libvir] Semantics for ListDomains/ ListDefinedDomains

[Daniel Veillard]

On Wed, Aug 23, 2006 at 05:15:26PM -0400, Daniel Veillard wrote:
> On Wed, Aug 23, 2006 at 09:22:08PM +0100, Daniel P. Berrange wrote:
> > On Wed, Aug 23, 2006 at 02:21:03PM -0400, Daniel Veillard wrote:
> > >   I was tempted to do an implementation just local to the library instance
> > > in the case there is no support by the virtualization engine. If you think
> > > you will use it then I should really implement it :-)
> > 
> > Trouble is I think we really badly need an implementation that is 
> > persistent. Tools like the 'xeninst[1]' package are using libvirt for
> > creating domains, but at the same time manually writing out config
> > files into /etc/xen - this means they are loosing an important benefit
> > of libvirt - namely isolation from Xen instability/changes. 
> > 
> > Now it would be pretty easy for libvirt to convert the XML file passed
> > into virDefineDomain into a config file for xend & stuf it in /etc/xen
> > The hard part is the reverse - enumerating the config files in the
> > dir & turning them back into XML. I fear we may have to tackle that
[...]
> >  * Write a tiny parser for a trivial subset - basically enough to
> >    handle the (key, string) pairs & (key, list of string) pairs.
> >    Certainly doable - depending on how general purpose we want to
> >    get - do we care about the 'if..else' conditional used in the
> >    sample /etc/xen/xmexample.vti config file ? We can certainly
> >    make a valid case saying we don't care about this because the
> >    libvirt XML -> xm config conversion would not generate config
> >    using that capability 
> 
>    I'm not too concerned by handling only a subset, this should be data
> and processed as such IMHO.
> 
> >  * Fork an unprivileged helper python program to exec the config 
> >    file and re-write it as XML which can be read back in by libvirt
> > 
> > The former is more work, but makes me feel better from a security
> > point of view.
> 
>   Writing a parser doesn't frighten me too much :-)
[...]
> > Not a perfect solution, but would satisfy a great deal of common
> > use cases pretty easily without being intrusive into existing code
> > base & pretty secure.
> 
>   We are basically in agreement :-)
> So I write that parser ? 

  Okay, there is a a first version in CVS under libvirt/src/conf.[ch]
It allows only variable assignments and comments, the types supported
are the [] lists, integers and strings. Still that should be sufficient
to handled  most data oriented existing Python Xen configurations.
  It supports load/lookup/writes as defined in conf.h:

-------------------------------------
typedef struct _virConf virConf;
typedef virConf *virConfPtr;

virConfPtr      virConfReadFile         (const char *filename);
virConfPtr      virConfReadMem          (const char *memory,
                                         int len);
int             virConfFree             (virConfPtr conf);

virConfValuePtr virConfGetValue         (virConfPtr conf,
                                         const char *setting);
int             virConfWriteFile        (const char *filename,
                                         virConfPtr conf);
int             virConfWriteMem         (char *memory,
                                         int *len,
                                         virConfPtr conf);
-------------------------------------

  Values are open structures:

-------------------------------------
/**
 * virConfType:
 * one of the possible type for a value from the configuration file
 *
 * TODO: we probably need a float too.
 */
typedef enum {
    VIR_CONF_NONE = 0,          /* undefined */
    VIR_CONF_LONG = 1,          /* a long int */
    VIR_CONF_STRING = 2,        /* a string */
    VIR_CONF_LIST = 3           /* a list */
} virConfType;

/**
 * virConfValue:
 * a value from the configuration file
 */
typedef struct _virConfValue virConfValue;
typedef virConfValue *virConfValuePtr;

struct _virConfValue {
    virConfType type;           /* the virConfType */
    virConfValuePtr next;       /* next element if in a list */
    long  l;                    /* long integer */
    char *str;                  /* pointer to 0 terminated string */
    virConfValuePtr list;       /* list of a list */
};
-------------------------------------

 If needed it's possible to lookup a value, change the object and save back,
I could extend the supported subset to handle expressions or reuse of variables
in assignments, but I'm not sure it is really worth it.
 The parser is strict, if it meets a construct it doesn't recognize it fails
and return NULL with an error.

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/