Re: [libvirt] [PATCH 00/22] Extend remote generator to generate function bodies too

2011/4/27 Daniel Veillard <veillard(a)redhat.com&gt;: > On Sun, Apr 24, 2011 at 11:13:47AM +0200, Matthias Bolte wrote: >> Richard W.M. Jones suggested [1] that the code that directly deals with the >> XDR protocol should be generated. The remote_generate_stubs.pl script >> already generates all the headers, just the bodies in the daemon and remote >> driver are manually written. But most of the functions just follow simple >> patterns. So I extended the generator to exploit this patterns and move >> 11 kLOC code from manually written to generated code. >> >> During this I came a cross many small variations and problems in the XDR >> protocol. For example, NWFilterDefineXML has a flags parameter in the public >> API, but it's not transferred in the XDR protocol. Another things is the >> variations in the usage of unsigned VS signed types. This comes in two forms. >> public API VS XDR procotol and in between different functions. For example, >> some functions use int for the flags paramater and some use unsigned int. >> >> This results in quite a lot of special case handling in the generator. > >  Matthias, > > this sounds the right thing to do, actually cocumenting the > irregularities in teh generator is an important step to make sure > we keep the ABI over time. However I think it's better to postpone > applying the patch since after the upcoming release and when > Dan is back, I would really prefer him to have a look at it :-) > >  okay ? > > Daniel Sure, this change is way to big to go into the next release, as we're supposed to be in feature freeze for 0.9.1 already, aren't we?

Although everything still compiles fine and the TCK did turn up any major breakage this needs to be properly reviewed to make sure I didn't overlook anything in the conversion process.

I should probably also add a 23/22 patch that adds more comments to the generator about the irregularities that are currently expressed by the special case code only.

So, as you said this series has to be postponed for 0.9.2.