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 638CAC433F5 for ; Tue, 28 Sep 2021 11:44: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 CD99D610E6 for ; Tue, 28 Sep 2021 11:44:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CD99D610E6 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]:49150 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mVBXV-0004R3-Vm for qemu-devel@archiver.kernel.org; Tue, 28 Sep 2021 07:44:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47876) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mVBRN-0007wu-8R for qemu-devel@nongnu.org; Tue, 28 Sep 2021 07:38:30 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:40687) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mVBRJ-0000F9-38 for qemu-devel@nongnu.org; Tue, 28 Sep 2021 07:38:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1632829103; 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=Q4MqSJCoWLiCg/h8l2EqcKSgdVBpe8dOCtRyo35H0LU=; b=iImSTn4/H7BQn7XuijwTLkmPj2v48cOSRjkKhFpu9vs0Tce+m0ybIC48gZLCZp+MVxYmM9 lWS2RJy/omuoUpGp6BCYk+21R11vL2mlFq6k6z3QhscyU2KNeM++q1pOGt3gKeN42pE4xA nPB07Qfr8ycOWwsxXccqnGIvqN1lzok= Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-531-qeFjjT-_P4O-bgdnlSldQA-1; Tue, 28 Sep 2021 07:38:21 -0400 X-MC-Unique: qeFjjT-_P4O-bgdnlSldQA-1 Received: by mail-pf1-f198.google.com with SMTP id z24-20020aa79f98000000b004463f2f0277so14362380pfr.23 for ; Tue, 28 Sep 2021 04:38:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q4MqSJCoWLiCg/h8l2EqcKSgdVBpe8dOCtRyo35H0LU=; b=mJ/aqY3almDmPhVS98D3Wc1oK14TzapAwdWmVJ0eoNDqU7Bfa5a5jc3fhoFecyiySW p7OR2RKwjkiewUYV0LoWbmZiZEUaTFA8J1cXCMciWWXgYNvrvCPsW7a/zCs3SE+wGzez NOfNItHuMZus8l7SnNwFos33HqiwtRdGvpYqtfwNlgcWddYl2xsw5iiNzoruoFNqHHJg F7TTijZyKzuEotkZM43fTUbEMBf6zeqhHs5T1Gg6kzSXOsihMpX7Anx2nnWgTF+X5uFr FdOizAoY0WaeoGC9mq+fB82+3IICCbiX3+VyvmFTLTF/7sc2u832W/mKQSGkQv50vuDj 1TRA== X-Gm-Message-State: AOAM533GzMB3GgpOzkpNo4G5RR0HxNmDy6703ILVdvzjUSbhS1zldHkq gA9RgbrTUnavVRX6uapL/I/k/bwcgGbxCw+iXIgDY19Ky5fDkvbL+X3dmKhC3USxqTSyr08dKi2 5i/+JVpp6qi6eHNIXCmZGBpmP7HtYwFg= X-Received: by 2002:a17:902:8bc1:b0:13d:e884:125a with SMTP id r1-20020a1709028bc100b0013de884125amr4632383plo.38.1632829100546; Tue, 28 Sep 2021 04:38:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyC4XpjruG5k1J7OLO4GU5awa9UEoCD4hMu0ByMRjWbsj9YdfcpxF2ctas3lucu36LqZB3bEdCWJPO0TL2YIy4= X-Received: by 2002:a17:902:8bc1:b0:13d:e884:125a with SMTP id r1-20020a1709028bc100b0013de884125amr4632360plo.38.1632829100189; Tue, 28 Sep 2021 04:38:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= Date: Tue, 28 Sep 2021 15:38:08 +0400 Message-ID: Subject: Re: QAPI sync meeting To: John Snow Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mlureau@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="0000000000007f02ad05cd0ca60b" Received-SPF: pass client-ip=216.205.24.124; envelope-from=mlureau@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, HTML_MESSAGE=0.001, 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: Markus Armbruster , qemu-devel Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --0000000000007f02ad05cd0ca60b Content-Type: text/plain; charset="UTF-8" Hi! On Mon, Sep 27, 2021 at 8:55 PM John Snow wrote: > Hiya, > > I'd like to propose that at least the three of us arrange a time to have a > meeting where we discuss our plans and ideas for QAPI going forward, > including rust, python, and golang extensions to the QAPI generator, what > we hope to accomplish with those projects, and so on. > > What I am hoping to get out of this for myself is a high-level overview of > people's plans for QAPI and to produce some notes on those plans so that I > can have a reference that we've all acknowledged as roughly accurate to be > able to keep the community's design goals for QAPI in mind as I continue my > own development. Ultimately, I'd like some kind of rough draft of a "QAPI > roadmap". > > I know there was a rust meetup during KVM Forum, but I was unable to > attend due to the timing. I'd like to expand the focus a little more > broadly to QAPI in general and discuss our "personal" roadmaps, goals, > queued work, etc so that we can collaboratively formulate a broader vision > of our work. > > I'm posting to qemu-devel in case anyone else has an interest in this area > and would like to eavesdrop or share opinions, but we should probably come > up with an agenda first. So: > > Proposed agenda: > > Current projects, wishlists, and goals for QAPI: > - Markus (~10 min) > - Marc-Andre (~10 min) (Rust, dbus, etc?) > The QAPI Rust binding RFC series aims to provide the QAPI types to Rust with to/from C translations. This is just one brick allowing QEMU to have some parts written in Rust: all other internal/subsystem binding pieces remain to be done. I don't have other plans for QAPI at this point. D-Bus (from the early qapi/rust series) was an experiment, showing that QAPI/QMP can be exposed via "serde" with almost no effort. (it could most likely be over other protocols, such as JSON, in full-Rust implementation). We can imagine sharing canonical QAPI IDLs for daemons/helpers written in different languages. However, the biggest hurdle when binding QAPI to D-Bus or many programming languages (c, python, go and rust foremost) is that it is not a machine/ABI-friendly IDL. QAPI doesn't impose orderdering of fields or arguments, and it is not versioned. I believe this is detrimental, because bindings have to be written and maintained by hand in various languages, with various flavours (some may add abstractions, some may version the schema themself, some may use plain dictionaries everywhere etc). The small flexibility advantage doesn't outweigh the cost. Imho, some of the pains of QAPI/QMP is that it's not so easy to interact with, either from a human point of view (who likes speaking JSON?) or a machine point of view (I don't have good bindings to use from my language of choice). If we provided (and generated) idiomatic client bindings, we would most likely have a few rules to not break them, and end up versionizing the schema (version the commands, version arguments etc, various options are possible). The wire format becomes a detail, and JSON can keep its own flexibility wrt fields ordering etc. - jsnow (~10 min) (Python, golang, etc) > > I am certainly interested to learn your updated plans. > Formulating short-term and long-term roadmaps: > - Open discussion, ~30 min > - Collaboratively produce a summary doc (etherpad?) outlining major work > to be done, separated into near and long terms > - Upload this summary to the QEMU wiki and mail it back out to qemu-devel > - We probably won't exactly finish this bit, but we can resume on the > mailing list afterwards perfectly well. > > (Feel free to propose anything different for the meeting, this is just a > jumping off point for discussion.) > > Proposed time: > > - Any weekday after 13:00 UTC. Wednesdays, Thursdays and Fridays work > particularly well for me at the moment. > That could work for me. - bluejeans and google meeting both work well for me. Open to alternatives. > > > Thanks, > --js > --0000000000007f02ad05cd0ca60b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi!

On Mon, Sep 27, 2021 at 8:55 PM Jo= hn Snow <jsnow@redhat.com> wr= ote:
Hiya,

I'd like to propose that at l= east the three of us arrange a time to have a meeting where we discuss our = plans and ideas for QAPI going forward, including rust, python, and golang = extensions to the QAPI generator, what we hope to accomplish with those pro= jects, and so on.

What I am hoping to get out of this for= myself is a high-level overview of people's plans for QAPI and to prod= uce some notes on those plans so that I can have a reference that we've= all acknowledged as roughly accurate to be able to keep the community'= s design goals for QAPI in mind as I continue my own development. Ultimatel= y, I'd like some kind of rough draft of a "QAPI roadmap".
=

I know there was a rust meetup during KVM Forum, = but I was unable to attend due to the timing. I'd like to expand the fo= cus a little more broadly to QAPI in general and discuss our "personal= " roadmaps, goals, queued work, etc so that we can collaboratively for= mulate a broader vision of our work.

I'm p= osting to qemu-devel in case anyone else has an interest in this area and w= ould like to eavesdrop or share opinions, but we should probably come up wi= th an agenda first. So:

Proposed agenda:
Current projects, wishlists, and goals for QAPI:
- M= arkus (~10 min)
- Marc-Andre (~10 min) (Rust, dbus, etc?)
=

The QAPI Rust binding RFC seri= es aims to provide the QAPI types to Rust with to/from C translations. This= is just one brick allowing QEMU to have some parts written in Rust: all ot= her internal/subsystem binding pieces remain to be done. I don't have o= ther plans for QAPI at this point.

D-Bus (from the early qapi/rust s= eries) was an experiment, showing that QAPI/QMP can be exposed via "se= rde" with almost no effort. (it could most likely be over other protoc= ols, such as JSON, in full-Rust implementation). We can imagine sharing can= onical QAPI IDLs for daemons/helpers written in different languages.
However, the biggest hurdle when binding QAPI to D-Bus or many programming= languages (c, python, go and rust foremost) is that it is not a machine/AB= I-friendly IDL. QAPI doesn't impose orderdering of fields or arguments,= and it is not versioned. I believe this is detrimental, because bindings h= ave to be written and maintained by hand in various languages, with various= flavours (some may add abstractions, some may version the schema themself,= some may use plain dictionaries everywhere etc). The small flexibility adv= antage doesn't outweigh the cost. Imho, some of the pains of QAPI/QMP i= s that it's not so easy to interact with, either from a human point of = view (who likes speaking JSON?) or a machine point of view (I don't hav= e good bindings to use from my language of choice). If we provided (and gen= erated) idiomatic client bindings, we would most likely have a few rules to= not break them, and end up versionizing the schema (version the commands, = version arguments etc, various options are possible). The wire format becom= es a detail, and JSON can keep its own flexibility wrt fields ordering etc.=

- jsnow (~10 min) (Python, golang, etc)


I am certainly in= terested to learn your updated plans.
=C2=A0
For= mulating short-term and long-term roadmaps:
- Open discussion, ~3= 0 min
- Collaboratively produce a summary doc (etherpad?) outlining majo= r work to be done, separated into near and long terms
- Uploa= d this summary to the QEMU wiki and mail it back out to qemu-devel
- We probably won't exactly finish this bit, but we can resume on= the mailing list afterwards perfectly well.

(Feel free t= o propose anything different for the meeting, this is just a jumping off po= int for discussion.)

Proposed time:

<= div>- Any weekday after 13:00 UTC. Wednesdays, Thursdays and Fridays work p= articularly well for me at the moment.
That could work for me.

- bluejea= ns and google meeting both work well for me. Open to alternatives.

<= /div>

Thanks,
--js
--0000000000007f02ad05cd0ca60b--