[RFC 00/29] RFC: Generate object-model code based on relax-ng files

[Daniel P. Berrangé]

On Wed, Mar 25, 2020 at 03:11:40PM +0800, Shi Lei wrote:
>  Outline
> =========
> 
> In libvirt world, objects(like domain, network, etc.) are described with two
> representations: structures in c-language and XML specified by relax-ng.
> Since c-language-implementation and xml restricted by relax-ng are merely
> the different expressions of the same object-model, we can make a tool to
> generate those C-language codes based on relax-ng files.
> 
> 
>  RNG2C tool
> ===========
> 
> RNG2C is a python tool which can translate hierarchy of notations
> in relax-ng into c-language structures. In general, <element> is converted to
> struct in C, struct's members derive from its <attribute>s and its sub <element>s;
> <choice> with multiple <value>s is converted to enum in C; <data> are converted
> into various builtin-type in C, such as int, char *.
> 
> Also, RNG2C can generate relative conversion functions: vir[XXX]ParseXML,
> vir[XXX]FormatBuf and vir[XXX]Clear.
> 
> These structures and functions can be used to replace hardcoded codes in current
> libvirt source.
> 
> The tool RNG2C has three subcommands: 'list', 'show' and 'generate'. The 'list' and
> 'show' are used for previewing generated code, and the 'generate' is prepared to be
> invoked by Makefile.

[snip]

Wow, this is a very impressive and ambitious bit of work, so
thanks for proposing this idea !

The idea of generating the XML parsers is pretty appealing and the
kind of thing I wish we had done right back at the very start of
libvirt development. I really came to like the idea of a metadata
driven XML parser when I created the libvirt-go-xml project structs.
As you already no doubt found, doing the auto-generation for integrating
into our existing code is even more tricky.

I expect the hardest parts are probably going to be bits of the schema
which are discriminated enums. These were what caused me most pain in
the Go XML bindings.

eg with disks where the "type=xxx" attribute on <disk> in turn controls
which child elements we accept in the parser. In the RNG schema we have
often been lazy and not represented the restrictions which are imposed
by the actual parser. Similarly in the actual structs, we often don;t
represent the discriminated enums conceptually.

IOW if we go down the route of generating everything from the RNG schema,
we're quite likely to need to do work to make the RNG schema more accurate.
We'll probably aso need to change a fair number of the struts we use. The
domain XML schema is the one most affected by this. All the other XML
schemas are fairly simple in general. None of this is a bad thing, but it
is potentially a lot of work. 

This is a big & complex series / topic, so it will take a little time
for me to properly review this idea and give some more detailed
feedback. So it will probably be next week before i reply again.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|