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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B4739C433F5 for ; Thu, 7 Oct 2021 12:58:03 +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 3C74661053 for ; Thu, 7 Oct 2021 12:58:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3C74661053 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:38756 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mYSyI-0001P1-9n for qemu-devel@archiver.kernel.org; Thu, 07 Oct 2021 08:58:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52268) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mYSuF-0003dY-3R for qemu-devel@nongnu.org; Thu, 07 Oct 2021 08:53:51 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:51541) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mYSuC-0001Ay-9q for qemu-devel@nongnu.org; Thu, 07 Oct 2021 08:53:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1633611227; 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=jSvxeCEW2wI3FiImPLAZtC4HxOyE2nUc5GELz6Dej/E=; b=NhC1zYMQeiQAY0SbtrAbXCrtDAfI+gSxWaxO6ErphveDHD3BTgnOFULjCCYVEz9NdcC1PD Mm5z/8SEdunMa/dd4w+aPE5iuQ1nReplsJy7ZSKtJnXeN4S56z7gY/8H1H5fCmELaquTpD iGBxKt3c1ioZSyza5QaYt8cD1CCH+Yg= 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-314-xwtkyBhCMC60mKECg_cDjQ-1; Thu, 07 Oct 2021 08:53:46 -0400 X-MC-Unique: xwtkyBhCMC60mKECg_cDjQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 37E5F802928 for ; Thu, 7 Oct 2021 12:53:45 +0000 (UTC) Received: from redhat.com (unknown [10.39.193.28]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1F3A25F4ED; Thu, 7 Oct 2021 12:53:20 +0000 (UTC) Date: Thu, 7 Oct 2021 14:53:19 +0200 From: Kevin Wolf To: Paolo Bonzini Subject: Re: QAPI sync meeting Message-ID: References: <87ee97y3q5.fsf@dusky.pond.sub.org> <3abc4e8e-5657-14bb-ba89-5b7669c01201@redhat.com> MIME-Version: 1.0 In-Reply-To: <3abc4e8e-5657-14bb-ba89-5b7669c01201@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 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=170.10.133.124; envelope-from=kwolf@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -28 X-Spam_score: -2.9 X-Spam_bar: -- X-Spam_report: (-2.9 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.05, 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_H2=-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: qemu-devel , Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= , John Snow , Markus Armbruster , =?iso-8859-1?Q?Marc-Andr=E9?= Lureau Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Am 07.10.2021 um 12:23 hat Paolo Bonzini geschrieben: > On 07/10/21 12:01, Kevin Wolf wrote: > > > > * -chardev: I have patches that QAPIfy the option based on aliases, > > getting rid of the old handwritten parser that is inconsistent with > > QMP in non-obvious ways and replacing it with translation to QMP > > (both using aliases and a little C code) that makes the differences > > obvious. > > > > First posted in November 2020, more details in the cover letter: > > https://patchew.org/QEMU/20201112175905.404472-1-kwolf@redhat.com/ > > > > Later versions (not yet posted as a series because I'm waiting for > > aliases) also make -chardev accept JSON syntax, which is what > > libvirt really wants to use. > > I'm still not sure about this... It's an awful lot of code if the aliases > are only used by -chardev, and I'd rather use -object/object-add for > chardevs if that's at all possible. The important part for me there is getting rid of the second parser that is inconsistent with QAPI - and people add to it without fully realising that it's a separate implementation, so they test -chardev and leave chardev-add behind broken. My approach keeps the existing command line syntax and still makes sure that inputs from both the CLI and QMP go through a single code path, making sure that they are consistent. Aliases are a helpful tool to achieve this, but the series can be rewritten a bit if people are fundamentally against having aliases. Aliases do nothing that C code can't do. I don't think that aliases are a lot of code, or even complicated code. Current v4 looks like a lot of lines of code because Markus made me add big comments everywhere and tons of tests. The actual code additions are rather small. But I also notice that there is resistance against having multiple ways to specify the same thing (which is the essence of aliases), so if people hate them, let's throw them away. The only part I really dislike with this scenario is that I could have been told almost a year ago... Anyway, your approach provides a different solution to the goal of getting rid of the second parser if you extend it: Add -object support to all chardev backends, then deprecate -chardev wholesale and drop it two releases later. This feels contentious, but I'm not opposed. Timeline: My series could be done for 6.2. Yours could have the replacement in 6.2 the earliest if we start working on it right now, then libvirt starts using it, deprecation in 7.0 or 7.1, then drop the old interface two releases later, i.e. December next year or March 2023. Kevin