From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:43737)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1UzSCa-0005Q5-Mt
	for qemu-devel@nongnu.org; Wed, 17 Jul 2013 09:55:36 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1UzSCY-0007uk-1L
	for qemu-devel@nongnu.org; Wed, 17 Jul 2013 09:55:32 -0400
Received: from mx1.redhat.com ([209.132.183.28]:44264)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1UzSCX-0007ug-Pp
	for qemu-devel@nongnu.org; Wed, 17 Jul 2013 09:55:29 -0400
Message-ID: <51E6A2D9.5040202@redhat.com>
Date: Wed, 17 Jul 2013 15:57:45 +0200
From: Laszlo Ersek <lersek@redhat.com>
MIME-Version: 1.0
References: <1374053373-30499-1-git-send-email-gaowanlong@cn.fujitsu.com>
	<1374053373-30499-2-git-send-email-gaowanlong@cn.fujitsu.com>
	<51E67368.3000003@redhat.com> <51E68D0F.4040503@redhat.com>
In-Reply-To: <51E68D0F.4040503@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH V5 01/12] NUMA: add NumaOptions,
 NumaNodeOptions and NumaMemOptions
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Eric Blake <eblake@redhat.com>
Cc: aliguori@us.ibm.com, ehabkost@redhat.com, qemu-devel@nongnu.org, peter.huangpeng@huawei.com, lcapitulino@redhat.com, bsd@redhat.com, y-goto@jp.fujitsu.com, pbonzini@redhat.com, afaerber@suse.de, Wanlong Gao <gaowanlong@cn.fujitsu.com>

On 07/17/13 14:24, Eric Blake wrote:
> On 07/17/2013 04:35 AM, Laszlo Ersek wrote:
> 
>>> +# @cpus: #optional VCPUs belong to this node
>>> +#
>>> +# Since: 1.6
>>> +##
>>> +{ 'type': 'NumaNodeOptions',
>>> +  'data': {
>>> +   '*nodeid':		'int',
>>> +   '*cpus':		'str' }}
>>> +
>>
>> Should we document the format for "cpus" here too?
> 
> Not only that, but is this even the right representation?  The fact that
> you are requiring the receiver to further parse this string means you
> probably represented it at the wrong level in JSON.  That is, a JSON
> string "1,2,4" requires post-processing to turn it into 3 processor ids,
> while a JSON array [1, 2, 4] does not, so you should probably consider
> '*cpus':['int'] as your preferred datatype.

opts-visitor can handle lists of simple scalar types. Ie. it can do
-numa node,nodeid=3,cpus=3-4,cpus=9-10. It can't save the parsing of
intervals (eg. 3-4).

This is of course not to say that the interface should be limited by
what opts-visitor can do; just that opts-visitor may not be appropriate
for (or solve completely the needs of) very intricate options.

Laszlo