From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f5rk6-0004QC-2R for qemu-devel@nongnu.org; Tue, 10 Apr 2018 07:47:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f5rk1-0006Vj-PA for qemu-devel@nongnu.org; Tue, 10 Apr 2018 07:47:17 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:33792 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f5rk1-0006VP-Jx for qemu-devel@nongnu.org; Tue, 10 Apr 2018 07:47:13 -0400 References: <20180407000117.25640-1-lersek@redhat.com> <979bd720-cdb3-6468-1fbd-e8ec1c6c6c8d@redhat.com> <8ddd0a2f-b9b1-08c0-0f4d-62e7aea7e96a@redhat.com> <20180410062754.eohou7i7chf6w65j@sirius.home.kraxel.org> <20180410092342.GH5155@redhat.com> From: Laszlo Ersek Message-ID: <9d6b3e23-ed02-0079-50d0-15de8b11810f@redhat.com> Date: Tue, 10 Apr 2018 13:46:55 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , "=?UTF-8?Q?Daniel_P._Berrang=c3=a9?=" Cc: Peter Maydell , Thomas Huth , Peter Krempa , Michael Roth , Ard Biesheuvel , libvir-list@redhat.com, Markus Armbruster , Kashyap Chamarthy , Alexander Graf , qemu-devel@nongnu.org, Gary Ching-Pang Lin , Gerd Hoffmann , Michal Privoznik , David Gibson On 04/10/18 12:09, Paolo Bonzini wrote: > On 10/04/2018 11:23, Daniel P. Berrang=C3=A9 wrote: >>> And, really, this seems to reinforce my point that the schema should >>> live in the libvirtd tree, not in the QEMU tree. In that case, perhap= s >>> it would be a better fit to work with an XSD, and firmware packages >>> should install XML files? Personally I'm a lot more attracted to >>> XML/XSD; I think the tooling is better too. I just don't see how QEMU= is >>> involved. >> >> This is defining a set of metadata that is required to use various fir= mware >> files in combination with QEMU, along with defining a mapping to QEMU = command >> line arguments and/or features. Essentially, while I wish everyone use= d >> libvirt, libvirt is not the only thing that manages QEMU. This informa= tion is >> relevant to anyone managing QEMU, so it doesn't belong in libvirt's re= alm, >> it is clear QEMU is best placed to declare this information. >=20 > QEMU is best placed to _standardize_ how to provide this information > (and where in the file system to place it), but really it's up to > firmware packages to provide it. >=20 > We can of course define the schema in QAPI terms for ease of validation > (machine-readable specs are nice to have), but really this should just > be a file in docs/interop/. No code is needed in QEMU. OK -- while we're figuring out the schema, I guess I'll keep posting RFCs that change source code / json, but finally we can move it to docs/interop. Thanks! Laszlo