From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40474 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OTFWH-00009g-HI for qemu-devel@nongnu.org; Mon, 28 Jun 2010 10:41:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OTFWC-0002LA-3e for qemu-devel@nongnu.org; Mon, 28 Jun 2010 10:41:09 -0400 Received: from goliath.siemens.de ([192.35.17.28]:16593) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OTFWB-0002K8-R0 for qemu-devel@nongnu.org; Mon, 28 Jun 2010 10:41:04 -0400 Message-ID: <4C28B47A.1040702@siemens.com> Date: Mon, 28 Jun 2010 16:40:58 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v4 11/23] monitor: Add completion support for option lists References: <68962306385412f48130690d29a0349b322b9930.1276641524.git.jan.kiszka@web.de> <4C21E1CB.6040600@siemens.com> <20100628112844.037d23cf@redhat.com> In-Reply-To: <20100628112844.037d23cf@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Anthony Liguori , Juan Quintela , Markus Armbruster , "qemu-devel@nongnu.org" , Blue Swirl , Jan Kiszka , Avi Kivity Luiz Capitulino wrote: > On Wed, 23 Jun 2010 12:28:27 +0200 > Jan Kiszka wrote: > >> Markus Armbruster wrote: >>> Jan Kiszka writes: >>> >>>> From: Jan Kiszka >>>> >>>> This enables command line completion inside option strings. A list of >>>> expected key names and their completion type can be appended to the 'O' >>>> inside parentheses ('O(key:type,...)'). The first use case is block >>>> device completion for the 'drive' option of 'device_add'. >>>> >>>> Signed-off-by: Jan Kiszka >>>> --- >>>> monitor.c | 68 ++++++++++++++++++++++++++++++++++++++++++++++--------- >>>> qemu-monitor.hx | 2 +- >>>> 2 files changed, 58 insertions(+), 12 deletions(-) >>>> >>>> diff --git a/monitor.c b/monitor.c >>>> index c1006b4..3e0d862 100644 >>>> --- a/monitor.c >>>> +++ b/monitor.c >>>> @@ -68,6 +68,9 @@ >>>> * 'O' option string of the form NAME=VALUE,... >>>> * parsed according to QemuOptsList given by its name >>>> * Example: 'device:O' uses qemu_device_opts. >>>> + * Command completion for specific keys can be requested via >>>> + * appending '(NAME:TYPE,...)' with 'F', 'B' as type. >>>> + * Example: 'device:O(bus:Q)' to expand 'bus=...' as qtree path. >>>> * Restriction: only lists with empty desc are supported >>>> * TODO lift the restriction >>>> * 'i' 32 bit integer >>> Ugh. >>> >>> Replacement of args_type by a proper data structure is long overdue. We >>> keep piling features into that poor, hapless string. >>> >>> Information on how to complete QemuOptsList options arguably belongs >>> into the option description, i.e. QemuOptDesc. >> For sure, that would be better. I just wonder how much of it should be >> stuffed into this series. I guess I will drop this part for now, just >> focusing on what device_show makes direct use of. Same for separate args >> for HMP and QMP. > > IIRC, the separate args idea use case was to allow commands like device_del > to have an ID argument and a path argument, right? If so, I think it doesn't > matter anymore as we have agreed on having a device argument which would > accept both, even under QMP, right Markus? To my understanding: As a leading element in qdev path, at least to address a device, maybe also to abbreviate only the beginning of a full path (that's currently to major remaining open issue). > > By the way, if you send patches 09/23, 10/23, 15/23, (maybe) 16/23, 21/23 > and 22/23 in a different series, I could try pushing them in my next > pull request. Do they need rebasing? If not, feel free to pick them up as you like. My series requires a v5 round anyway once discussion on path construction finally came to an end. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux