From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MjDEo-00055T-A0 for qemu-devel@nongnu.org; Thu, 03 Sep 2009 10:24:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MjDEj-00052F-6T for qemu-devel@nongnu.org; Thu, 03 Sep 2009 10:24:33 -0400 Received: from [199.232.76.173] (port=32992 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MjDEj-00052A-1Y for qemu-devel@nongnu.org; Thu, 03 Sep 2009 10:24:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59506) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MjDEi-0003V0-GO for qemu-devel@nongnu.org; Thu, 03 Sep 2009 10:24:28 -0400 From: Luiz Capitulino Date: Thu, 3 Sep 2009 11:24:14 -0300 Message-Id: <1251987859-20254-1-git-send-email-lcapitulino@redhat.com> Subject: [Qemu-devel] [RFC 0/5] Monitor handlers convertion to QObject List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: aliguori@us.ibm.com, avi@redhat.com Hi There, This is a RFC for the next phase of the QEMU Monitor Protocol project, in this phase handlers will get fully "structurized". I was waiting for the first phase to be merged before sending this, but as it's already in staging and as this is just a RFC, I've decided to send. This series adds the infrastructure needed to accommodate the new style handlers and ports do_info_balloon() and do_balloon() to QObject style. Please, note that I've chosen to stay simple. I already have patches for QList and advanced stuff (like the 'ninja action' suggested by Anthony) but for now let's concentrate on design decisions that will impact the protocol format. Besides the 'user_print' approach, it's very important to discuss the following: 1. Return data -------------- For do_info_balloon() I'm always returning a QString. The 'actual' info could be something else (QDict?), but I think QString is good, because it's simple. Choosing the best set of data types to return is an issue and I don't think we can have a general rule for this, the solution will be to review *each* command handler port and be sure we are doing the right thing. I hope people don't get bored in reviewing. 2. Return code -------------- All handlers will have a return code. For this series they return 0 for success and -1 for error. My current plan is that the procotol will *always* emit something like: { "__result__": 0, "__data__": { ... } } Where the standard keys 'result' and 'data' will be pushed by common code (monitor_handle_command(), in this case). Some people have suggested us to define errors codes, but I dislike this because I have the impression we will end up defining errors per-handlers, which is a lot of work and more protocol definitions to maintain. Another issue in this subject is that sometimes we will have to do a not so small refactor to get the proper error code. I mean, sometimes the functions which the handlers call return void, and those functions in turn call other functions which also return void. This seem to be the case of do_balloon(), for example. A possible solution is to only return error when it's easy, otherwise we could always return 0 (which is what we have today), the problem though is that changing this in the future will cause trouble. Suggestions?