From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1BE1EC433E0 for ; Thu, 11 Mar 2021 11:42:51 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7220564FC9 for ; Thu, 11 Mar 2021 11:42:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7220564FC9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:56024 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lKJiL-00046x-6R for qemu-devel@archiver.kernel.org; Thu, 11 Mar 2021 06:42:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38336) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lKJhW-0003OT-Lc for qemu-devel@nongnu.org; Thu, 11 Mar 2021 06:41:59 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:42749) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1lKJhT-0007Fq-UM for qemu-devel@nongnu.org; Thu, 11 Mar 2021 06:41:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615462914; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tZ/JPgeGOBRRsb4PNQjAyItP5a9Mu8t1X/km7wT7KvU=; b=EqunzN8MxVbKg4JFtEotfV5wkX1vCSDAUbXUZT5nl7NHUYMgSIUtihxdPQ/K6PMtxv50n+ PmGK3fR++htTZygXyMzcSJgVagu8tK3KZwXW2COK5xlTs5OksITnLIZgTHzRS8C34jDk4Y 2wSxjaaHpzCkBcXDnG92DU8olfbjH6g= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-429--VLxWFusOUuNp2BkctLqiQ-1; Thu, 11 Mar 2021 06:41:53 -0500 X-MC-Unique: -VLxWFusOUuNp2BkctLqiQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 17F678189CD; Thu, 11 Mar 2021 11:41:52 +0000 (UTC) Received: from merkur.fritz.box (ovpn-114-112.ams2.redhat.com [10.36.114.112]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AF17160853; Thu, 11 Mar 2021 11:41:43 +0000 (UTC) Date: Thu, 11 Mar 2021 12:41:42 +0100 From: Kevin Wolf To: Peter Krempa Subject: Re: [PATCH v3 00/30] qapi/qom: QAPIfy --object and object-add Message-ID: <20210311114142.GE9008@merkur.fritz.box> References: <20210308165440.386489-1-kwolf@redhat.com> <90130a0c-7f96-f344-b185-b790c5d6b78a@redhat.com> <20210310173044.GF6076@merkur.fritz.box> <20210311083711.GA9008@merkur.fritz.box> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kwolf@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Received-SPF: pass client-ip=216.205.24.124; envelope-from=kwolf@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -29 X-Spam_score: -3.0 X-Spam_bar: --- X-Spam_report: (-3.0 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: lvivier@redhat.com, thuth@redhat.com, ehabkost@redhat.com, qemu-block@nongnu.org, libvir-list@redhat.com, jasowang@redhat.com, qemu-devel@nongnu.org, mreitz@redhat.com, kraxel@redhat.com, Paolo Bonzini , dgilbert@redhat.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Am 11.03.2021 um 12:24 hat Peter Krempa geschrieben: > On Thu, Mar 11, 2021 at 09:37:11 +0100, Kevin Wolf wrote: > > Am 11.03.2021 um 08:47 hat Peter Krempa geschrieben: > > > On Wed, Mar 10, 2021 at 18:30:44 +0100, Kevin Wolf wrote: > > > > Am 10.03.2021 um 15:31 hat Paolo Bonzini geschrieben: > > > > > On 10/03/21 15:22, Peter Krempa wrote: > > [...] > > > > -object memory-backend-ram,id=ram-node2,size=24578621440,host-nodes=1-2,host-nodes=5,host-nodes=7,policy=bind > > > > Oh, we have ranges, too... That makes the compatibility code even > > nastier to write. I doubt that we can implement this in the keyval > > parser alone without touching the visitor. :-/ > > > > > If any of the above is to be deprecated we'll need to adjust our > > > JSON->commandline generator accordignly. > > > > > > Luckily the 'host-nodes' is storeable as a bitmap and the generator is > > > actually modular to allow plugging an array interpretor which actually > > > does the above conversion from a JSON array. > > > > > > So, what is the preferred syntax here? Additionally we might need a > > > witness property to detect when to use the new syntax if basing it on > > > the object-add qapification will not be enough. > > > > The list syntax supported by the keyval parser is the one you know from > > -blockdev: host-nodes.0=3,host-nodes.1=7, ... > > I think that should be easy enough to convert to. We could also support JSON syntax in QEMU. That would probably be even more convenient for libvirt? > Is it safe to do right away (with the old parser?). Otherwise we need > to agree on something which will let us detect when it's safe to > change. Neither keyval nor JSON syntax work with the old QemuOpts parser. What is the usual way to do this for command line options? If we don't have a good way there, we can always tie it to something in the QAPI schema. If we still get this solved in time for 6.0, we could use the existence of ObjectOptions. Or all else failing, we can use a feature flag. Kevin