Re: Summary of Re: Making QEMU easier for management tools and applications

On Wed, Feb 12, 2020 at 01:54:42PM +, Stefan Hajnoczi wrote: > On Mon, Feb 10, 2020 at 05:43:13PM +0100, Markus Armbruster wrote: > > Stefan Hajnoczi writes: > > > > > On Tue, Feb 4, 2020 at 3:54 PM Markus Armbruster > > > wrote: > > >> = Ways to provide machine-friendly initial

Re: Summary of Re: Making QEMU easier for management tools and applications

On Mon, Feb 10, 2020 at 05:43:13PM +0100, Markus Armbruster wrote: > Stefan Hajnoczi writes: > > > On Tue, Feb 4, 2020 at 3:54 PM Markus Armbruster wrote: > >> = Ways to provide machine-friendly initial configuration = > >> > >> Two ways to provide machine-friendly initial configuration on par

Re: Summary of Re: Making QEMU easier for management tools and applications

Stefan Hajnoczi writes: > On Tue, Feb 4, 2020 at 3:54 PM Markus Armbruster wrote: >> = Ways to provide machine-friendly initial configuration = >> >> Two ways to provide machine-friendly initial configuration on par with >> QMP have been proposed: >> >> 1. Extend QMP >> >>Machines use the

Re: Summary of Re: Making QEMU easier for management tools and applications

On Mon, 10 Feb 2020 at 11:08, Daniel P. Berrangé wrote: > > On Mon, Feb 10, 2020 at 11:01:48AM +, Peter Maydell wrote: > > On Mon, 10 Feb 2020 at 10:57, Stefan Hajnoczi wrote: > > > I'm in favor of simplifying QEMU at the expense of an incompatible CLI > > > change in QEMU 6.0. > > > > If we

Re: Summary of Re: Making QEMU easier for management tools and applications

On Mon, Feb 10, 2020 at 11:01:48AM +, Peter Maydell wrote: > On Mon, 10 Feb 2020 at 10:57, Stefan Hajnoczi wrote: > > I'm in favor of simplifying QEMU at the expense of an incompatible CLI > > change in QEMU 6.0. > > If we want to do wholesale incompatible changes to the CLI > I think we

Re: Summary of Re: Making QEMU easier for management tools and applications

On 10/02/20 11:56, Stefan Hajnoczi wrote: > On Tue, Feb 4, 2020 at 3:54 PM Markus Armbruster wrote: >> = Ways to provide machine-friendly initial configuration = >> >> Two ways to provide machine-friendly initial configuration on par with >> QMP have been proposed: >> >> 1. Extend QMP >> >>

Re: Summary of Re: Making QEMU easier for management tools and applications

On Mon, 10 Feb 2020 at 10:57, Stefan Hajnoczi wrote: > I'm in favor of simplifying QEMU at the expense of an incompatible CLI > change in QEMU 6.0. If we want to do wholesale incompatible changes to the CLI I think we definitely need some kind of tool where a user can say "here's my old command

Re: Summary of Re: Making QEMU easier for management tools and applications

On Tue, Feb 4, 2020 at 3:54 PM Markus Armbruster wrote: > = Ways to provide machine-friendly initial configuration = > > Two ways to provide machine-friendly initial configuration on par with > QMP have been proposed: > > 1. Extend QMP > >Machines use the CLI only to configure a QMP socket.

Re: qmp-shell for GSoC/Outreachy? (Was: Re: Making QEMU easier for management tools and applications)

* John Snow (js...@redhat.com) wrote: > I'm forking the subject as I believe Markus wanted to focus on the > machine interface aspect. > > I feel that a new human interface is *related* to that goal: the > splitting of, and commitment to, separate human and machine interfaces > powered by a

qmp-shell for GSoC/Outreachy? (Was: Re: Making QEMU easier for management tools and applications)

I'm forking the subject as I believe Markus wanted to focus on the machine interface aspect. I feel that a new human interface is *related* to that goal: the splitting of, and commitment to, separate human and machine interfaces powered by a single root schema. I am a big believer in making QEMU

Re: Making QEMU easier for management tools and applications

Am 28.01.2020 um 11:59 hat Kevin Wolf geschrieben: > > > The other part that it needs to solve is how to be available by default > > > without specifying anything on the command line. Basically, if I press > > > Ctrl-Alt-2, I want to get to a monitor shell. If that shell is > > > implemented

Re: Summary of Re: Making QEMU easier for management tools and applications

Markus Armbruster writes: [...] > = Ways to provide machine-friendly initial configuration = > > Two ways to provide machine-friendly initial configuration on par with > QMP have been proposed: > > 1. Extend QMP > >Machines use the CLI only to configure a QMP socket. The remainder >of

Summary of Re: Making QEMU easier for management tools and applications

This thread has accumulated more than a hundred messages over seven weeks. We need a summary. The conversation has gone in several directions. In this message, I'll cover just the one I consider most important: machine-friendly initial configuration. I'll do the rest later, if I have stamina

Re: Making QEMU easier for management tools and applications

Andrea Bolognani writes: > On Fri, 2020-01-31 at 07:50 +0100, Markus Armbruster wrote: >> Kevin Wolf writes: >> > Much of this threads plays with the though that maybe we don't need any >> > compatibility and make the radical conclusion that we don't need any >> > human-friendly interface at

Re: Improving QOM documentation [Was: Re: Making QEMU easier for management tools and applications]

Paolo Bonzini writes: > On 03/02/20 10:54, Markus Armbruster wrote: >>> Types are documented as above; however types other than link<> and >>> child<>, which are QAPI types, can be user-defined types (structs, >>> enums) and this is not included in (1). >> Specifically, three of four kinds of

Re: Making QEMU easier for management tools and applications

On Fri, 2020-01-31 at 07:50 +0100, Markus Armbruster wrote: > Kevin Wolf writes: > > Much of this threads plays with the though that maybe we don't need any > > compatibility and make the radical conclusion that we don't need any > > human-friendly interface at all. Keeping full compatibility is

Re: Improving QOM documentation [Was: Re: Making QEMU easier for management tools and applications]

On 03/02/20 10:54, Markus Armbruster wrote: >> Types are documented as above; however types other than link<> and >> child<>, which are QAPI types, can be user-defined types (structs, >> enums) and this is not included in (1). > Specifically, three of four kinds of type names are documented: >

Re: Improving QOM documentation [Was: Re: Making QEMU easier for management tools and applications]

Paolo Bonzini writes: > On 31/01/20 18:23, Markus Armbruster wrote: >> Kashyap Chamarthy writes: >> docs/devel/qapi-code-gen.txt has the same problem: it's mostly internal >> stuff, but there's also introspection, which is an external interface. > > We should move introspection to docs/interop.

Re: Improving QOM documentation [Was: Re: Making QEMU easier for management tools and applications]

On 31/01/20 18:23, Markus Armbruster wrote: > Kashyap Chamarthy writes: > docs/devel/qapi-code-gen.txt has the same problem: it's mostly internal > stuff, but there's also introspection, which is an external interface. We should move introspection to docs/interop. Any takers? >> Rigorous

Re: Making QEMU easier for management tools and applications

Markus Armbruster writes: > Paolo Bonzini writes: > >> Il dom 2 feb 2020, 10:22 Kevin Wolf ha scritto: >> >>> Am 31.01.2020 um 13:27 hat Eric Blake geschrieben: >>> > On 1/28/20 6:54 AM, Kevin Wolf wrote: >>> > >>> > > > >>> > > > The arguments as dotted keys: >>> > > > >>> > > >

Re: Making QEMU easier for management tools and applications

Paolo Bonzini writes: > Il dom 2 feb 2020, 10:22 Kevin Wolf ha scritto: > >> Am 31.01.2020 um 13:27 hat Eric Blake geschrieben: >> > On 1/28/20 6:54 AM, Kevin Wolf wrote: >> > >> > > > >> > > > The arguments as dotted keys: >> > > > >> > > >

Re: Making QEMU easier for management tools and applications

Il dom 2 feb 2020, 10:22 Kevin Wolf ha scritto: > Am 31.01.2020 um 13:27 hat Eric Blake geschrieben: > > On 1/28/20 6:54 AM, Kevin Wolf wrote: > > > > > > > > > > The arguments as dotted keys: > > > > > > > > id=bar,backend.type=file,backend.data.out=/tmp/bar.log > > > > > > > > Observe

Re: Making QEMU easier for management tools and applications

Am 31.01.2020 um 13:27 hat Eric Blake geschrieben: > On 1/28/20 6:54 AM, Kevin Wolf wrote: > > > > > > > The arguments as dotted keys: > > > > > > id=bar,backend.type=file,backend.data.out=/tmp/bar.log > > > > > > Observe there's quite some of nesting. While that's somewhat cumbersome >

Re: Improving QOM documentation [Was: Re: Making QEMU easier for management tools and applications]

Kashyap Chamarthy writes: > On Fri, Jan 31, 2020 at 12:02:05PM +0100, Paolo Bonzini wrote: >> Il ven 31 gen 2020, 11:36 Peter Maydell ha >> scritto: > > [...] > >> The advantage of putting them in the header is that you have them all in >> one place (inline functions and structs must be in the

Re: Improving QOM documentation [Was: Re: Making QEMU easier for management tools and applications]

Paolo Bonzini writes: > Il ven 31 gen 2020, 11:36 Peter Maydell ha > scritto: > >> On Fri, 31 Jan 2020 at 06:11, Markus Armbruster wrote: >> > Beware, personal opinion. >> > >> > When you put documentation next to the code it documents (which you >> > absolutely should, because it's your only

Re: Improving QOM documentation [Was: Re: Making QEMU easier for management tools and applications]

On 31/01/20 16:37, Christophe de Dinechin wrote: > > >> On 31 Jan 2020, at 08:46, Paolo Bonzini wrote: >> >> On 31/01/20 07:11, Markus Armbruster wrote: >>> May I present you Armbru's Comment Trust Levels: >>> >>> ACTL2: The comment may be overly terse or incomplete, but the >>> probability for

Re: Improving QOM documentation [Was: Re: Making QEMU easier for management tools and applications]

> On 31 Jan 2020, at 08:46, Paolo Bonzini wrote: > > On 31/01/20 07:11, Markus Armbruster wrote: >> May I present you Armbru's Comment Trust Levels: >> >> ACTL2: The comment may be overly terse or incomplete, but the >> probability for it to be outright wrong is low. >> >> ACTL1: Treat as

Re: Improving QOM documentation [Was: Re: Making QEMU easier for management tools and applications]

On Fri, Jan 31, 2020 at 12:02:05PM +0100, Paolo Bonzini wrote: > Il ven 31 gen 2020, 11:36 Peter Maydell ha > scritto: [...] > The advantage of putting them in the header is that you have them all in > one place (inline functions and structs must be in the header). In practice > that balances

Re: Making QEMU easier for management tools and applications

On 1/28/20 6:54 AM, Kevin Wolf wrote: The arguments as dotted keys: id=bar,backend.type=file,backend.data.out=/tmp/bar.log Observe there's quite some of nesting. While that's somewhat cumbersome in JSON, it's a lot worse with dotted keys, because there nesting means repeated key

Re: Making QEMU easier for management tools and applications

On 1/28/20 9:36 AM, Markus Armbruster wrote: Cc: Eric for netdev_add QAPIfication. These are the known "cheats" in QMP. There's also netdev_add, but Eric has patches to QAPIfy it properly. Eric, I hope you can dust them off. Yes, I'll move that up on my todo list. When I originally did

Re: Improving QOM documentation [Was: Re: Making QEMU easier for management tools and applications]

Il ven 31 gen 2020, 11:36 Peter Maydell ha scritto: > On Fri, 31 Jan 2020 at 06:11, Markus Armbruster wrote: > > Beware, personal opinion. > > > > When you put documentation next to the code it documents (which you > > absolutely should, because it's your only realistic chance to keep the > >

Re: Improving QOM documentation [Was: Re: Making QEMU easier for management tools and applications]

On Fri, 31 Jan 2020 at 06:11, Markus Armbruster wrote: > Beware, personal opinion. > > When you put documentation next to the code it documents (which you > absolutely should, because it's your only realistic chance to keep the > two in sync), then extracting API comments is useful, because it >

Re: Improving QOM documentation [Was: Re: Making QEMU easier for management tools and applications]

On Fri, Jan 31, 2020 at 07:11:15AM +0100, Markus Armbruster wrote: > Kashyap Chamarthy writes: [...] > > What can be done to improve QOM documentation (or lack thereof)? > > Are you trying to push us from idle grousing to actually improve things? > No fair! I first wrote it as a

Re: Making QEMU easier for management tools and applications

Paolo Bonzini writes: > On 31/01/20 07:50, Markus Armbruster wrote: Consider chardev-add. Example: {"execute": "chardev-add", "arguments": {"id": "bar", "backend": {"type": "file", "data": {"out":

Re: Making QEMU easier for management tools and applications

On 31/01/20 07:50, Markus Armbruster wrote: >>> Consider chardev-add. Example: >>> >>> {"execute": "chardev-add", >>> "arguments": {"id": "bar", >>>"backend": {"type": "file", >>>"data": {"out": "/tmp/bar.log" >>> >>> The arguments

Re: Improving QOM documentation [Was: Re: Making QEMU easier for management tools and applications]

On 31/01/20 07:11, Markus Armbruster wrote: > May I present you Armbru's Comment Trust Levels: > > ACTL2: The comment may be overly terse or incomplete, but the > probability for it to be outright wrong is low. > > ACTL1: Treat as helpful guidance (with gratitude), but trust only the > code. >

Re: Making QEMU easier for management tools and applications

Kevin Wolf writes: > Am 28.01.2020 um 13:36 hat Markus Armbruster geschrieben: >> Kevin Wolf writes: >> >> > Am 27.01.2020 um 21:11 hat John Snow geschrieben: >> [...] >> >> (The argument here is: It's a little harder and a little longer to type, >> >> but the benefits from the schema

Re: Improving QOM documentation [Was: Re: Making QEMU easier for management tools and applications]

Kashyap Chamarthy writes: > On Wed, Jan 15, 2020 at 03:02:48PM +0100, Markus Armbruster wrote: >> Daniel P. Berrangé writes: > > [Changed the subject-line to indicate deviation from the original > topic.] > > [...] > >> > Libvirt is of course happy to switch to something else instead of >> >

Improving QOM documentation [Was: Re: Making QEMU easier for management tools and applications]

On Wed, Jan 15, 2020 at 03:02:48PM +0100, Markus Armbruster wrote: > Daniel P. Berrangé writes: [Changed the subject-line to indicate deviation from the original topic.] [...] > > Libvirt is of course happy to switch to something else instead of > > qom-set for these features if QEMU wants to

Re: Making QEMU easier for management tools and applications

On 1/28/20 5:16 AM, Markus Armbruster wrote: > I'm deeply skeptical of any solution that starts with inventing a > new language. Start with examining existing ones instead. I promise that we are in violent agreement. Later in the mail: "Any prior art, other projects, and reading anyone can

Re: Making QEMU easier for management tools and applications

Cc: Eric for netdev_add QAPIfication. Kevin Wolf writes: > Am 28.01.2020 um 11:16 hat Daniel P. Berrangé geschrieben: >> On Mon, Jan 27, 2020 at 11:38:49PM +0100, Paolo Bonzini wrote: >> > Il lun 27 gen 2020, 21:11 John Snow ha scritto: >> > >> > > >> > > > ./qemu-core <> > > { >> > >

Re: Making QEMU easier for management tools and applications

> > Consider chardev-add. Example: > > > > {"execute": "chardev-add", > > "arguments": {"id": "bar", > >"backend": {"type": "file", > >"data": {"out": "/tmp/bar.log" > Well, first of all: Do we need compatibility? Well, libvirt

Re: Making QEMU easier for management tools and applications

Am 28.01.2020 um 13:36 hat Markus Armbruster geschrieben: > Kevin Wolf writes: > > > Am 27.01.2020 um 21:11 hat John Snow geschrieben: > [...] > >> (The argument here is: It's a little harder and a little longer to type, > >> but the benefits from the schema organization may improve productivity

Re: Making QEMU easier for management tools and applications

Kevin Wolf writes: > Am 27.01.2020 um 21:11 hat John Snow geschrieben: [...] >> (The argument here is: It's a little harder and a little longer to type, >> but the benefits from the schema organization may improve productivity >> of using QEMU directly instead of harming it.) > > I think this is

Re: Making QEMU easier for management tools and applications

Am 27.01.2020 um 21:29 hat Dr. David Alan Gilbert geschrieben: > * Kevin Wolf (kw...@redhat.com) wrote: > > A command history already exists for qmp-shell. It's better than bash > > because it doesn't mix QMP history with whatever else I do on my > > computer. > > > > Autocomplete in qmp-shell

Re: Making QEMU easier for management tools and applications

Am 28.01.2020 um 11:16 hat Daniel P. Berrangé geschrieben: > On Mon, Jan 27, 2020 at 11:38:49PM +0100, Paolo Bonzini wrote: > > Il lun 27 gen 2020, 21:11 John Snow ha scritto: > > > > > > > > > ./qemu-core < > > { > > > "machine": "Q35", > > > "memory": "2GiB", > > > "accel": "kvm" >

Re: Making QEMU easier for management tools and applications

Am 27.01.2020 um 21:11 hat John Snow geschrieben: > On 1/27/20 6:56 AM, Kevin Wolf wrote: > > Am 25.01.2020 um 11:18 hat Markus Armbruster geschrieben: > >> Kevin Wolf writes: > >>> basically just a pretty-printed version of it with the consequence that > >>> it needs to be stored in an external

Re: Making QEMU easier for management tools and applications

On Mon, Jan 27, 2020 at 11:38:49PM +0100, Paolo Bonzini wrote: > Il lun 27 gen 2020, 21:11 John Snow ha scritto: > > > > > > ./qemu-core < > { > > "machine": "Q35", > > "memory": "2GiB", > > "accel": "kvm" > > } > > EOF > > > > And now you have to keep all the syntactic sugar that

Re: Making QEMU easier for management tools and applications

John Snow writes: > On 1/27/20 9:35 AM, Kevin Wolf wrote: >> Am 24.01.2020 um 10:50 hat Daniel P. Berrangé geschrieben: >>> On Thu, Jan 23, 2020 at 04:07:09PM -0500, John Snow wrote: Well, sure. The context of this email was qmp-shell though, which is meant to help facilitate the entry

Re: Making QEMU easier for management tools and applications

On 1/27/20 5:38 PM, Paolo Bonzini wrote: > > > Il lun 27 gen 2020, 21:11 John Snow > ha scritto: > > > > ./qemu-core < { >     "machine": "Q35", >     "memory": "2GiB", >     "accel": "kvm" > } > EOF > > > And now you have to keep all

Re: Making QEMU easier for management tools and applications

Il lun 27 gen 2020, 21:11 John Snow ha scritto: > > > ./qemu-core < { > "machine": "Q35", > "memory": "2GiB", > "accel": "kvm" > } > EOF > And now you have to keep all the syntactic sugar that is in vl.c. I don't think a redesign of -readconfig should accept anything less verbose

Re: Making QEMU easier for management tools and applications

On 1/27/20 9:35 AM, Kevin Wolf wrote: > Am 24.01.2020 um 10:50 hat Daniel P. Berrangé geschrieben: >> On Thu, Jan 23, 2020 at 04:07:09PM -0500, John Snow wrote: >>> Well, sure. The context of this email was qmp-shell though, which is >>> meant to help facilitate the entry of JSON commands so

Re: Making QEMU easier for management tools and applications

* Kevin Wolf (kw...@redhat.com) wrote: > Am 24.01.2020 um 10:50 hat Daniel P. Berrangé geschrieben: > > On Thu, Jan 23, 2020 at 04:07:09PM -0500, John Snow wrote: > > > Well, sure. The context of this email was qmp-shell though, which is > > > meant to help facilitate the entry of JSON commands so

Re: Making QEMU easier for management tools and applications

* Kevin Wolf (kw...@redhat.com) wrote: > Am 25.01.2020 um 11:18 hat Markus Armbruster geschrieben: > > Kevin Wolf writes: > > > > > Am 24.01.2020 um 11:27 hat Daniel P. Berrangé geschrieben: > > >> This is finally something I'd consider to be on a par with the > > >> original QEMU syntax, before

Re: Making QEMU easier for management tools and applications

On 1/27/20 6:56 AM, Kevin Wolf wrote: > Am 25.01.2020 um 11:18 hat Markus Armbruster geschrieben: >> Kevin Wolf writes: >> >>> Am 24.01.2020 um 11:27 hat Daniel P. Berrangé geschrieben: This is finally something I'd consider to be on a par with the original QEMU syntax, before we

Re: Making QEMU easier for management tools and applications

On 1/25/20 6:41 AM, Paolo Bonzini wrote: > On 20/01/20 10:55, Stefan Hajnoczi wrote: >>> >>> [1] https://qemu.readthedocs.io/en/latest/interop/live-block-operations.html >> John and I discussed async events in the past. qmp-shell currently uses >> the input() built-in function. If we modify

Re: Making QEMU easier for management tools and applications

Hi, > > We already have qapi schema for -blockdev + -display + -audiodev + > > -chardev, creating a configuration struct which supports these > > shouldn't be that much effort. Then move over QemuOpts one by one. > > chardev-add uses a QAPI type that has too deep nesting to be user > friendly.

Re: Making QEMU easier for management tools and applications

Am 24.01.2020 um 10:50 hat Daniel P. Berrangé geschrieben: > On Thu, Jan 23, 2020 at 04:07:09PM -0500, John Snow wrote: > > Well, sure. The context of this email was qmp-shell though, which is > > meant to help facilitate the entry of JSON commands so that you *can* > > indeed just forego the

Re: Making QEMU easier for management tools and applications

Daniel P. Berrangé writes: > On Sat, Jan 25, 2020 at 11:18:41AM +0100, Markus Armbruster wrote: >> Kevin Wolf writes: >> >> > Am 24.01.2020 um 11:27 hat Daniel P. Berrangé geschrieben: >> >> So if we allowed YAML instead of JSON, now we get... >> >> >> >> $ cat qemu.yaml [...] >> >> This is

Re: Making QEMU easier for management tools and applications

Am 27.01.2020 um 09:35 hat Gerd Hoffmann geschrieben: > Hi, > > > We build a "configuration" struct in QAPI, and extend from there. > > > > (2) We offer "--config myconfig.yaml" as an option for specifying > > options. > > Yes. > > > This precludes the use of *any* traditional command line

Re: Making QEMU easier for management tools and applications

On Mon, 27 Jan 2020 at 11:56, Kevin Wolf wrote: > If you have a long-lived production VM that you always run with the same > configuration, then yes, having a config file for it in the file system > is what you probably want. Currently, for this case, people directly > using QEMU tend to write a

Re: Making QEMU easier for management tools and applications

Am 25.01.2020 um 11:18 hat Markus Armbruster geschrieben: > Kevin Wolf writes: > > > Am 24.01.2020 um 11:27 hat Daniel P. Berrangé geschrieben: > >> This is finally something I'd consider to be on a par with the > >> original QEMU syntax, before we added hierarchical data. You > >> have the

Re: Making QEMU easier for management tools and applications

On Sat, Jan 25, 2020 at 11:18:41AM +0100, Markus Armbruster wrote: > Kevin Wolf writes: > > > Am 24.01.2020 um 11:27 hat Daniel P. Berrangé geschrieben: > >> So if we allowed YAML instead of JSON, now we get... > >> > >> $ cat qemu.yaml > >> --- > >> arguments: > >> - arg: object > >>

Re: Making QEMU easier for management tools and applications

On Sat, Jan 25, 2020 at 12:52:30PM +0100, Paolo Bonzini wrote: > On 24/01/20 10:50, Daniel P. Berrangé wrote: > > * qemu-launcher-$TARGET > > > > A binary that is able to launch qemu-runtime-$TARGET > > with jailers active. > > > > This has no command line arguments except for a

Re: Making QEMU easier for management tools and applications

On Mon, Jan 27, 2020 at 10:06:45AM +0100, Markus Armbruster wrote: > Daniel P. Berrangé writes: > > * qemu-system-$TARGET > > > > The current binaries that exist today. > > > > qemu-system-$TARGET should not be part of our formal > > stability promise. We won't gratuitously /

Re: Making QEMU easier for management tools and applications

Paolo Bonzini writes: > Il mer 15 gen 2020, 10:21 Markus Armbruster ha scritto: > >> > We don’t want the QAPI to let arbitrary fields of a QOM object >> > be modified, do we? >> >> We already do: QMP command qom-set. If it breaks your guest, you get to >> keep the pieces. >> > > That's not

Re: Making QEMU easier for management tools and applications

Daniel P. Berrangé writes: > On Thu, Jan 23, 2020 at 04:07:09PM -0500, John Snow wrote: >> >> >> On 1/23/20 2:01 PM, Daniel P. Berrangé wrote: [...] >> > I guess my point is that with a scrap & startover view point, we >> > should arguably completely ignore the design question of how to >> >

Re: Making QEMU easier for management tools and applications

Hi, > We build a "configuration" struct in QAPI, and extend from there. > > (2) We offer "--config myconfig.yaml" as an option for specifying > options. Yes. > This precludes the use of *any* traditional command line flags. Hmm. Given that the transition effort will probably take a while I

Tooling to help humans use JSON (was: Making QEMU easier for management tools and applications)

Daniel P. Berrangé writes: > On Thu, Jan 23, 2020 at 04:07:09PM -0500, John Snow wrote: >> >> >> On 1/23/20 2:01 PM, Daniel P. Berrangé wrote: [...] >> Well, sure. The context of this email was qmp-shell though, which is >> meant to help facilitate the entry of JSON commands so that you *can*

Re: Making QEMU easier for management tools and applications

> On 23 Jan 2020, at 18:58, John Snow wrote: > > > > On 1/23/20 2:19 AM, Markus Armbruster wrote: >> John Snow writes: >> >>> On 12/24/19 8:41 AM, Daniel P. Berrangé wrote: > * scripts/qmp/qmp-shell > > Half-hearted attempt at a human-friendly wrapper around the JSON >

Re: Making QEMU easier for management tools and applications

Il mer 15 gen 2020, 10:21 Markus Armbruster ha scritto: > > We don’t want the QAPI to let arbitrary fields of a QOM object > > be modified, do we? > > We already do: QMP command qom-set. If it breaks your guest, you get to > keep the pieces. > That's not true. We chose not to make that a

Re: Making QEMU easier for management tools and applications

On 24/12/19 14:41, Daniel P. Berrangé wrote: > I'm wondering if we need to think about a temporary *throwaway* fork of > QEMU. I wasn't involved in the work, but as an outside observer I think > it is interesting to see how the NEMU project fork ultimately led to QEMU > moving forward with a new

Re: Making QEMU easier for management tools and applications

On 24/01/20 10:50, Daniel P. Berrangé wrote: > * qemu-launcher-$TARGET > > A binary that is able to launch qemu-runtime-$TARGET > with jailers active. > > This has no command line arguments except for a pair > of UNIX socket paths. One is a QMP server, the other > is the

Re: Making QEMU easier for management tools and applications

On 20/01/20 10:55, Stefan Hajnoczi wrote: >> >> [1] https://qemu.readthedocs.io/en/latest/interop/live-block-operations.html > John and I discussed async events in the past. qmp-shell currently uses > the input() built-in function. If we modify it with a > select(2)/poll(2)-style function that

Re: Making QEMU easier for management tools and applications

Kevin Wolf writes: > Am 24.01.2020 um 11:27 hat Daniel P. Berrangé geschrieben: >> On Fri, Jan 24, 2020 at 08:59:41AM +0100, Markus Armbruster wrote: >> > John Snow writes: >> > >> > > On 1/23/20 2:01 PM, Daniel P. Berrangé wrote: >> > >> So when configuring objects you'll always provide a

Re: Making QEMU easier for management tools and applications

On 1/24/20 2:59 AM, Markus Armbruster wrote: > Digression: JSON is a poor choice for configuration files. YAML is a > complex and confusing beast (it's spec is printed 116 pages, and > yaml-0.2.2/src is ~7kSLOC). XML is XML, 'nuff said. TOML is much > simpler than either of the two. JSON has

Re: Making QEMU easier for management tools and applications

On 1/24/20 1:52 PM, Dr. David Alan Gilbert wrote: > * John Snow (js...@redhat.com) wrote: >> >> >> On 1/24/20 1:30 PM, Dr. David Alan Gilbert wrote: >>> However, I caution that too many people think that QMP has all the type >>> of diagnostic stuff people want - it's just way too hard and

Re: Making QEMU easier for management tools and applications

* John Snow (js...@redhat.com) wrote: > > > On 1/24/20 1:30 PM, Dr. David Alan Gilbert wrote: > > However, I caution that too many people think that QMP has all the type > > of diagnostic stuff people want - it's just way too hard and beuracratic > > to add a simple diagnostic command to QMP,

Re: Making QEMU easier for management tools and applications

On 1/24/20 1:30 PM, Dr. David Alan Gilbert wrote: > However, I caution that too many people think that QMP has all the type > of diagnostic stuff people want - it's just way too hard and beuracratic > to add a simple diagnostic command to QMP, when you just want to add > something to print some

Re: Making QEMU easier for management tools and applications

* John Snow (js...@redhat.com) wrote: > > > On 1/24/20 9:38 AM, Kevin Wolf wrote: > > Hi! :-) > > > > Well, not fighting for it to the death and I'm certainly not married to > > its exact syntax, but I use HMP all the time because it's convenient to > > use manually and QMP isn't. > > > > If

Re: Making QEMU easier for management tools and applications

On 1/24/20 9:38 AM, Kevin Wolf wrote: > Hi! :-) > > Well, not fighting for it to the death and I'm certainly not married to > its exact syntax, but I use HMP all the time because it's convenient to > use manually and QMP isn't. > > If you want to remove HMP, get us a decent QMP shell first.

Re: Making QEMU easier for management tools and applications

Am 24.01.2020 um 11:27 hat Daniel P. Berrangé geschrieben: > On Fri, Jan 24, 2020 at 08:59:41AM +0100, Markus Armbruster wrote: > > John Snow writes: > > > > > On 1/23/20 2:01 PM, Daniel P. Berrangé wrote: > > >> So when configuring objects you'll always provide a JSON/YAML doc. > > >> They've

Re: Making QEMU easier for management tools and applications

On Fri, Jan 24, 2020 at 08:59:41AM +0100, Markus Armbruster wrote: > John Snow writes: > > > On 1/23/20 2:01 PM, Daniel P. Berrangé wrote: > >> So when configuring objects you'll always provide a JSON/YAML doc. > >> They've got some clever stuff for updating objects where you can > >> provide a

Re: Making QEMU easier for management tools and applications

On Thu, Jan 23, 2020 at 04:07:09PM -0500, John Snow wrote: > > > On 1/23/20 2:01 PM, Daniel P. Berrangé wrote: > > IOW, the difficulty with configuring QEMU via JSON is not the fault > > of JSON itself, it is the lack of knowledge amongst users and docs, > > compounded by our never ending

Re: Making QEMU easier for management tools and applications

John Snow writes: > On 1/23/20 2:01 PM, Daniel P. Berrangé wrote: >> On Thu, Jan 23, 2020 at 12:58:45PM -0500, John Snow wrote: >>> Yes, I agree: Scrap and start over. >>> >>> What SHOULD the syntax look like, though? Clearly the idea of qmp-shell >>> is that it offers a convenient way to enter

Re: Making QEMU easier for management tools and applications

John Snow writes: > On 1/23/20 2:19 AM, Markus Armbruster wrote: [...] >> Any conventional parser can be made streaming by turning it into a >> coroutine. This is probably the simplest solution for handwritten >> streaming LL parsers, because it permits recursive descent. In Python, >> I'd try

Re: Making QEMU easier for management tools and applications

On 1/23/20 2:01 PM, Daniel P. Berrangé wrote: > On Thu, Jan 23, 2020 at 12:58:45PM -0500, John Snow wrote: >> Yes, I agree: Scrap and start over. >> >> What SHOULD the syntax look like, though? Clearly the idea of qmp-shell >> is that it offers a convenient way to enter the top-level keys of

Re: Making QEMU easier for management tools and applications

On Thu, Jan 23, 2020 at 12:58:45PM -0500, John Snow wrote: > Yes, I agree: Scrap and start over. > > What SHOULD the syntax look like, though? Clearly the idea of qmp-shell > is that it offers a convenient way to enter the top-level keys of the > arguments dict. This works absolutely fine right

Re: Making QEMU easier for management tools and applications

On 1/23/20 2:19 AM, Markus Armbruster wrote: > John Snow writes: > >> On 12/24/19 8:41 AM, Daniel P. Berrangé wrote: * scripts/qmp/qmp-shell Half-hearted attempt at a human-friendly wrapper around the JSON syntax. I have no use for this myself. >>> I use this fairly

Re: Making QEMU easier for management tools and applications

On Thu, Jan 23, 2020 at 01:13:33PM -0500, John Snow wrote: > > > On 1/23/20 5:27 AM, Daniel P. Berrangé wrote: > > On Wed, Jan 22, 2020 at 05:42:10PM -0500, John Snow wrote: > >> > >> > >> On 12/24/19 8:00 AM, Daniel P. Berrangé wrote: > >>> Based on experiance in libvirt, this is an even larger

Re: Making QEMU easier for management tools and applications

On 1/23/20 5:27 AM, Daniel P. Berrangé wrote: > On Wed, Jan 22, 2020 at 05:42:10PM -0500, John Snow wrote: >> >> >> On 12/24/19 8:00 AM, Daniel P. Berrangé wrote: >>> Based on experiance in libvirt, this is an even larger job than (4), >>> as the feature set here is huge. Much of it directly

Re: Making QEMU easier for management tools and applications

On Wed, Jan 22, 2020 at 05:42:10PM -0500, John Snow wrote: > > > On 12/24/19 8:00 AM, Daniel P. Berrangé wrote: > > Based on experiance in libvirt, this is an even larger job than (4), > > as the feature set here is huge. Much of it directly ties into the > > config problem, as to deal with

Re: Making QEMU easier for management tools and applications

John Snow writes: > On 12/24/19 8:41 AM, Daniel P. Berrangé wrote: >>> * scripts/qmp/qmp-shell >>> >>> Half-hearted attempt at a human-friendly wrapper around the JSON >>> syntax. I have no use for this myself. >> I use this fairly often as its a useful debugging / experimentation >> /

Re: Making QEMU easier for management tools and applications

John Snow writes: > On 12/24/19 8:00 AM, Daniel P. Berrangé wrote: >> Based on experiance in libvirt, this is an even larger job than (4), >> as the feature set here is huge. Much of it directly ties into the >> config problem, as to deal with SELinux / namespace setup the code >> needs to

Re: Making QEMU easier for management tools and applications

On 12/24/19 8:00 AM, Daniel P. Berrangé wrote: > Based on experiance in libvirt, this is an even larger job than (4), > as the feature set here is huge. Much of it directly ties into the > config problem, as to deal with SELinux / namespace setup the code > needs to understand what resources

Re: Making QEMU easier for management tools and applications

On 12/24/19 8:41 AM, Daniel P. Berrangé wrote: >> * scripts/qmp/qmp-shell >> >> Half-hearted attempt at a human-friendly wrapper around the JSON >> syntax. I have no use for this myself. > I use this fairly often as its a useful debugging / experimentation > / trouble shooting tool.

Re: Integrating QOM into QAPI (was: Making QEMU easier for management tools and applications)

On Tue, Jan 21, 2020 at 02:36:17PM +0100, Markus Armbruster wrote: > Marc-André Lureau writes: > > > Hi > > > > On Tue, Jan 21, 2020 at 3:32 PM Stefan Hajnoczi wrote: > >> > >> On Tue, Jan 21, 2020 at 06:42:47AM +0100, Markus Armbruster wrote: > >> > Stefan Hajnoczi writes: > >> > > >> > > On

Integrating QOM into QAPI (was: Making QEMU easier for management tools and applications)

Marc-André Lureau writes: > Hi > > On Tue, Jan 21, 2020 at 3:32 PM Stefan Hajnoczi wrote: >> >> On Tue, Jan 21, 2020 at 06:42:47AM +0100, Markus Armbruster wrote: >> > Stefan Hajnoczi writes: >> > >> > > On Wed, Jan 15, 2020 at 01:15:17PM +0100, Markus Armbruster wrote: >> > >> Christophe de

Re: Making QEMU easier for management tools and applications

Hi On Tue, Jan 21, 2020 at 3:32 PM Stefan Hajnoczi wrote: > > On Tue, Jan 21, 2020 at 06:42:47AM +0100, Markus Armbruster wrote: > > Stefan Hajnoczi writes: > > > > > On Wed, Jan 15, 2020 at 01:15:17PM +0100, Markus Armbruster wrote: > > >> Christophe de Dinechin writes: > > >> >> On 15 Jan

Re: Making QEMU easier for management tools and applications

On Tue, Jan 21, 2020 at 06:42:47AM +0100, Markus Armbruster wrote: > Stefan Hajnoczi writes: > > > On Wed, Jan 15, 2020 at 01:15:17PM +0100, Markus Armbruster wrote: > >> Christophe de Dinechin writes: > >> >> On 15 Jan 2020, at 10:20, Markus Armbruster wrote: > >> *

  1   2   >