On Wed, 16 Mar 2011 10:59:33 -0500 Anthony Liguori <anth...@codemonkey.ws> wrote:
> On 03/16/2011 09:34 AM, Luiz Capitulino wrote: > > On Fri, 11 Mar 2011 17:05:30 -0600 > > Anthony Liguori<aligu...@us.ibm.com> wrote: > > > >> For more information about the background of QAPI, see > >> http://wiki.qemu.org/Features/QAPI > >> > >> This series depends on 'QAPI Round 0' which I posted earlier. > >> > >> Since v2, the major changes are: > >> > >> - Switch to a multiline code emitter to ease readability > >> - Use named parameters for escape sequences > >> - Add support for proxy commands > >> - Add support for asynchronous commands > >> > >> This version still adds a -qmp2 option. This is the only practical way I > >> know > >> to have testable code while not merging 200 patches all at once. > > I've started reviewing this and my first impression is that this seems to be > > real good. However, there's a lot of code here and some parts of it are a > > bit > > complicated, so I need more time to do a thorough review and testing. > > > > Having said that, my only immediate concern is weather this will have any > > negative side effects on the wire protocol, today or in the future. > > > > I mean, a C library has different extensibility constraints and > > functionality > > requirements than a high-level protocol and tying/mixing the two can have > > bad side effects, like this small one (patch 12/15): > > C library is not quite as important as C interface. I want QMP to be an > interface that we consume internally because that will make QMP a strong > external interface. Agreed. > A fundamental design characteristic for me is that first and foremost, > QMP should be a good C interface and that the wire representation should > be easy to support in a good C interface. Agreed. > This is a shift in our direction but the good news is that the practical > impact is small. But I don't think there's a lot of value of focusing > on non-C consumers because any non-C consumer is capable of consuming a > good C interface (but the inverse is not true). I disagree. To access a C interface from a high-level language you usually have to write bindings. Using something like QMP instead of writing bindings is a lot easier. Also, what's the problem with C consumers using QMP? Libvirt is C, and it does it just fine. So, my personal position on shifting the direction is: I think it's if we treat the C interface as something internal to QEMU. > > +## > > +# @put_event: > > +# > > +# Disconnect a signal. This command is used to disconnect from a signal > > based > > +# on the handle returned by a signal accessor. > > +# > > +# @tag: the handle returned by a signal accessor. > > +# > > +# Returns: Nothing on success. > > +# If @tag is not a valid handle, InvalidParameterValue > > +# > > +# Since: 0.15.0 > > > > The name 'signal' (at least today) doesn't make sense on the wire protocol, > > 'put_event' probably doesn't make sense in the C library, nor does 'event'. > > I tried very hard to make events useful without changing the wire > protocol significantly but I've failed there. > > I've got a new proposal for handling events that introduces the concept > of a signal on the wire and the notion of connecting and disconnecting > from signals. Ok. > > > Another detail is that, event extension is more important than command > > extension, because it's probably going to happen. I think it would be very > > bad to add new events just because we wanted to add a new field. > > The way this is typically handled is that signals tend to pass > structures instead of lots of fields. For instance, most of the GDK > events just pass a structure for the event (like GdkButtonEvent). > > > Most of these problems seems to go away just by making libqmp internal > > to QEMU, then I think all this work would rock big time :-) > > For 0.15.0, libqmp is internal to QEMU. We need to think very hard > before making it an external interface. Ok. > But the same sort of compatibility considerations apply to using QMP > within QEMU. If you add a new field to a function call, we need to > modify any internal usage of the API. What's the problem of doing this? > If we add a field to a structure, > as long as we use feature flags (we do), only the places that care to > set that field need to worry about it. Why do we need this in an internal interface?
