* 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 that you *can* > > > indeed just forego the CLI/HMP entirely. > > > > > > If you are of the opinion that every user of QEMU should be copy/pasting > > > JSON straight into a socket and we should delete qmp-shell, that's > > > certainly a fine opinion. > > > > I think part of the pain of qmp-shell comes from the very fact that > > it is trying to be an interactive shell. This points people towards > > interactively typing in the commands, which is horrific when you get > > anywhere near the JSON, or even dot-notation traditional commands. > > > > If it was just a qmp-client that was single shot, we'd encourage > > people to create the JSON in a sensible way - vim/emacs/whatever. > > I don't see how this is sensible. QMP commands are something that I > reuse even less than VM configurations, so creating a one-off file for > each would take me a lot more time and I would still have to type the > same JSON code that I have to type with -qmp stdio. > > The reason it is and should be an interactive shell is that I'm > interacting with it. Switching back and forth between a text editor and > a shell to actually send the command to QEMU would make things only even > more cumbersome than they already are. > > > Bash/dash/zsh/$whatever is their interactive shell, with massively > > more features than qmp-shell. You have command history, autocomplete, > > conditional and looping constructs, and everything a normal shell > > offers. > > If I wanted to program a QMP client, I would use Python. For me, > conditionals and loops are completely out of scope for a QMP shell. I > just want an easy way to tell QEMU to do something specific. > > 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 doesn't exist, as far as I know, but if > implemented, it could be a lot more useful than bash completion because > it could offer key completion based on the QMP schema. > > This is in fact a big part of the problem that qmp-shell really needs to > solve before it can replace HMP: How to make writing commands at least > almost as simple as with HMP. If I can just press tab a few times to > cycle through the available options for the command, that would already > be a massive improvement over writing JSON manually (which you would > still have to do with your text-file based approach, without any > QMP-specific support).
Doing all that in a python process (i.e. an actual python shell with a bunch of qemu commands added) seems easyish. > 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 internally or by an external Python process, I don't mind. That is a harder part. (I rarely use Ctrl-Alt-2 actually; I mostly use HMP on stdin). Dave > > The only strong reason for qmp-shell to be interactive would be if > > the initial protoocl handshake was too slow. I can't see that being > > a problem with QMP. > > Speed would be the least of my concerns. This is about manual use, and > it already takes me a while to type in my commands. > > > Example usage: > > > > 1. Launch the QEMU runtime for the desired target > > > > $ qemu-runtime-x86_64 myvm.sock > > > > 2. Load the configuration to define the VM > > > > $ cat myvm.yaml > > commands: > > - machine_declare: > > name: pc-q35-5.0 > > ... > > - blockdev_add: > > ... > > - device_add: > > ... > > - blockdev_add: > > ... > > - device_add: > > ... > > $ qemu-client myvm.sock myvm.yaml > > > > > > 3. Hotplug a disk > > > > $ cat mynewdisk.yaml > > commands: > > - blockdev_add: > > ... > > - device_add: > > ... > > $ qemu-client myvm.sock mynewdisk.yaml > > > > > > 3. Hotunplug a disk > > > > $ cat myolddisk.yaml > > commands: > > - device_del: > > ... > > - blockdev_del: > > ... > > $ qemu-client myvm.sock myolddisk.yaml > > Just to compare, this is what the human user oriented flow looks like > today: > > 1. qemu-system-x86_64 -M pc-q35-5.0 -drive if=virtio,... -cdrom ... > > 2. <Press Ctrl-Alt-2 to get to the HMP shell> > (qemu) drive_add ... > <Press Ctrl-Alt-1 to get back to the guest> > > 3. <Press Ctrl-Alt-2 to get to the HMP shell> > (qemu) device_del ... > <Press Ctrl-Alt-1 to get back to the guest> > > This is what we're competing with, and honestly I don't see how your > qemu-runtime-*/qemu-client based flow comes even close to it in terms of > usability. > > QMP, JSON and YAML may be nice machine interfaces, but having nice > machine interfaces doesn't mean that you shouldn't also have something > that is suitable for humans. qmp-shell is trying to be that, and while > it leaves much to be desired in its current state, replacing it with > even more machine-friendly stuff that is cumbersome for humans isn't the > right answer. > > Kevin > > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
