On Tue, 08 Jun 2010 11:01:19 -0500 Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote: > On 06/08/2010 10:05 AM, Chris Wright wrote: [...] > > migration events? > > - QMP (wire protocol) has nice async events > > - QError reasonable > > - migration is async command, can complete w/ error or success > > - QMP broken for error > > - need context for error, default is monitor, but async command > > - redo qerror_report, propagate error (or always have error context > > available) > > - monitor and qmp done w/ same dispatch functions > > - should do monitor in terms of qmp > > - every qerror replacing monitor printf error > > - ends up not sharing enough ($foo not found, where $foo is contextual) > > - async command (pass in command completion) > > - may have to do limited (throw away for 0.13 and redo properly for 0.14) > > - anthony has a (not fully working) tree, and will document direction on wiki > > Nice summary. > > http://wiki.qemu.org/Features/QMP2 Nice page, except that its original name raised the question whether current QMP was going to be thrown away and done from scratch :-) I agree on most points and yes, we have issues with QError and async commands. However, as we talked by IRC, I think we should define what's blocker for 0.13 and what's ok to be postponed. IMO, there are two classes of problems that have to be fixed for 0.13: 1. Client visible changes 2. Any issue that makes QMP not work as specified by its documentation Async commands is item 2, but it doesn't look that serious to me provided that, as you said, we ensure that commands don't run in parallel and that query-balloon (our only async command) doesn't hit the issue. The decoupling of QMP and HMP is something I really wanted to do, but this is clearly not 0.13 material. Also note that the monitor state before QMP was quite horrible, it's slightly better now, but main point is: we would not have QMP today if we would fix/cleanup all the problems we've found, specially because some problems span the monitor code base. Now, QError. This is something I think we should fix for 0.13. However, I still don't know how to get it right: most of what you say in the wiki page has already been discussed before. For example, you suggest the error object should be returned, this is probably a requirement to have async commands working, but this thread explains the problems we had with that: http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg00818.html Another issue is that QErrors are getting too specific. I see two problems here, first how errors should be done and how to map errno properly, also already discussed: http://lists.gnu.org/archive/html/qemu-devel/2010-05/msg00314.html Finally, sometimes handler A and handler B can share the error class but not the error context. I can't locate a good example right now, but this becomes evident if you have a 1:1 mapping between QError and errno (eg, EINVAL can be anything), so it's hard to share errors in this case and we end up creating new ones. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
