qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making QEMU easier for management tools and applications


From: Dr. David Alan Gilbert
Subject: Re: Making QEMU easier for management tools and applications
Date: Mon, 27 Jan 2020 20:12:59 +0000
User-agent: Mutt/1.13.0 (2019-11-30)

* Kevin Wolf (address@hidden) wrote:
> Am 25.01.2020 um 11:18 hat Markus Armbruster geschrieben:
> > Kevin Wolf <address@hidden> 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 minimal possible amount of syntax here. No commas,
> > >> no quotes, no curly brackets, etc.
> > >
> > > This seems to have the same problems as the QEMU command line (how do
> > > you distinguish strings from ints, from bools, from null?).
> > 
> > True: YAML provides only string scalars.
> > 
> > TOML provides strings, integers, floats, booleans, and several flavors
> > of time.  It lacks null.
> > 
> > >                                                             It's
> > > basically just a pretty-printed version of it with the consequence that
> > > it needs to be stored in an external file and there is no reasonable way
> > > to keep it in my shell history.
> > 
> > There is a reasonable way to keep it in my file system, though.  I find
> > that decidedly superior.
> 
> That depends a lot on your use case.
> 
> 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 script that contains the command line. I
> think I do have such scripts somewhere, but their number is very small.
> 
> My common case is short-lived VMs with configurations that change very
> often between QEMU invocations. Here the command line is decidedly
> superior.

I can imagine you could do something similar to gdb's --eval-command
option which lets you pass a command to be executed at startup; gdb's
syntax is a bit painful but it feels like that could be fixed, e.g. I
have:

gdb --eval-command='set pagination off' --eval-command='set confirm no' 
--eval-command='handle SIGPIPE print pas
s nostop' --eval-command='handle SIGBUS print pass nostop' --eval-command=r 
--eval-command='thread apply all bt full'
 --eval-command='info proc mappings' --eval-command='info threads' 
--eval-command=q --args $QEMUTODEBUG "$@"

in a script.

Dave

> Requiring me to create a file in the file system each time and to
> remember deleting it after I'm done feels about as convenient as a *nix
> shell that doesn't accept parameters for commands on the command line,
> but instead requires you to write a one-off script first and then run
> that.
> 
> Kevin
> 
> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK




reply via email to

[Prev in Thread] Current Thread [Next in Thread]