Re: [Xen-devel] [PATCH 07 of 10] pyxl: Recursively scan type-tree to produce complete binding boilerplate

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Gianni Tedesco writes ("Re: [Xen-devel] [PATCH 07 of 10] pyxl: Recursively scan 
type-tree to produce complete binding boilerplate"):
> We discussed this off-list at the time I was writing it. I think with
> one of the other guys. We decided that const char * in the interface was
> a bad idea since it imposed an allocation policy where no reason for it
> actually existed in the code. I could have worked around this by casting
> everything in the python bindings but we felt that was an ugly solution
> and not a good precedent to set.

Right.

However: There was no explanation of this change in your patch
comment.  It should probably have been a separate patch anyway.
Furthermore, if you had agreement from anyone else that this change
should be made despite the freeze I'm afraid you didn't mention it.

> You are right that it changes the code and may incorrectly free the ""
> allocated in libxl_dm.c - I could strdup() in that instance that but the
> interface is changed so we have a problem. Alternatively I can change 2
> lines in genwrap.py to emit correct code for this.

All of these are possibilities but I think this series should probably
wait for 4.2 now.

> > So I'm pushing 1-6 and the rest will have to wait for after the 4.1
> > release, I'm afraid.
> 
> Your chainsaw.... my baby... :(

There is no point saying we're having a freeze if we always let new
stuff in anyway.  I think this is beyond the scope of the exception we
should make at this stage.  Feel free to try to convince me otherwise.

Sorry.

As we have just discussed if you want to resubmit the rest of the
series in a way that doesn't change the autogenerated code, then I'm
happy to apply it on the basis that it's (a) a bugfix to the python
bindings (which are broken right now) and (b) low risk if it really
doesn't change the autogenerated code.

If you need to do something which changes the autogenerated code then
I'll be wanting a second opinion at least.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel