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=-5.0 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 39EFBC433E0 for ; Mon, 22 Feb 2021 18:04:52 +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 CAED264D9C for ; Mon, 22 Feb 2021 18:04:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CAED264D9C 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]:40586 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lEFZi-0000pB-SJ for qemu-devel@archiver.kernel.org; Mon, 22 Feb 2021 13:04:50 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58494) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lEFXA-0006wQ-7A for qemu-devel@nongnu.org; Mon, 22 Feb 2021 13:02:13 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:35204) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1lEFX3-00043f-PY for qemu-devel@nongnu.org; Mon, 22 Feb 2021 13:02:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1614016925; h=from:from:reply-to: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=IDcPCbkKtDJxPr45czbgaT02f4DIQ3Ja1wgv++iyUfs=; b=CgExR4ne6v6JcJWHs0YIST/fyWgrMkcIHOl/1gi34AZe9WCB5ptFviJcwczRb6/4F0Vv9v TgN2BF0VRNUpcmI0v0cDiN4JnYauCpfc2aV/zKAxj0/Gykz51mrs5SU3LoRRzUTammt7Da XZR1ZSBm/5fIO3WRJeVu1ABZwedohrs= 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-383-scKIVtL3PA2lKS6MeesT_Q-1; Mon, 22 Feb 2021 13:02:00 -0500 X-MC-Unique: scKIVtL3PA2lKS6MeesT_Q-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 92C80107ACF7; Mon, 22 Feb 2021 18:01:59 +0000 (UTC) Received: from redhat.com (ovpn-115-70.ams2.redhat.com [10.36.115.70]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 04B6D60DA0; Mon, 22 Feb 2021 18:01:54 +0000 (UTC) Date: Mon, 22 Feb 2021 18:01:52 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Paolo Bonzini Subject: Re: A brief look at deprecating our JSON extensions over RFC 8259 Message-ID: References: <875z2knoa5.fsf@dusky.pond.sub.org> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.0.5 (2021-01-21) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=berrange@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Received-SPF: pass client-ip=216.205.24.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Cc: libvir-list@redhat.com, Peter Maydell , John Snow , Markus Armbruster , qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Mon, Feb 22, 2021 at 06:42:00PM +0100, Paolo Bonzini wrote: > On 22/02/21 15:57, Markus Armbruster wrote: > > * The block layer's pseudo-protocol "json:" (which can get embedded in > > image headers) > > If it gets embedded in image headers, I don't think we'll be able to > deprecate it ever. We'd need to keep a converter for old images, at which > point it's simpler to keep the extensions. Even if we can only use a standard JSON parser for QMP + QGA, that's a already a significant net win long term IMHO. Both of those are security critical components and also areas where we might want different language impls as we increasingly use a multi-process model, so avoiding use of extensins is good. Even for the block layer, we don't neccessarily need to keep compat at runtime. It could be sufficient to have an extended deprecation period and then provide an offline helper script to re-write the qcow2 backing store field to use " instead of ' ....assuming we actually get real world pushback from people who really have used ' - we don't know if there are such people yet. We can do deprecation in a multi stage process - deprecation for everything, then block it for QMP + QGA after 2 cycles, while still allowing it for qcow2, and eventually block for qcow2 3 years later or something like that. IOW, I wouldn't give up on trying to deprecate it. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|