qemu-devel
[Top][All Lists]
Advanced

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

Re: Command line QAPIfication and -readconfig


From: Kevin Wolf
Subject: Re: Command line QAPIfication and -readconfig
Date: Wed, 11 Nov 2020 13:53:07 +0100

Am 11.11.2020 um 12:07 hat Paolo Bonzini geschrieben:
> On 11/11/20 11:35, Kevin Wolf wrote:
> > > IOW, I'd suggest we focus effort on introducing the new config file format
> > > based on QAPI first, and once that exists, then convert these sample
> > > config files in docs/config, and deprecate -readconfig.
> > 
> > Fine with me. That would make introducing the new config file format a
> > priority, though, even if it can't support every option yet (similar to
> > -readconfig). I didn't have the impression so far that we are planning
> > to do that. Is anyone working on it?
> 
> Indeed, my plan was to focus on QMP-based configuration, not on
> configuration file formats.
> 
> However I hit the same snag, in that my patches broke -readconfig for
> -object, -M and -accel.  I'm thinking of decoupling config file parsing from
> QemuOpts, using QDicts instead and moving the QemuOpts part into
> softmmu/vl.c.

QDicts are one step closer to the final result, but would also have to
be processed separately as they need only half of the processing that
command line options need. Eventually, qobject_input_visitor_new_str()
is what we want to use to parse strings directly into QAPI objects, and
QDicts are only an internal intermediate result there.

So while it's even uglier, maybe what we should do with -readconfig is
convert it back to strings and then run the result through the normal
command line processing? This would get rid of the special cases.

Both options are probably only hacks for the short term, so either way I
think I'd still prefer deprecating -readconfig now, in favour of command
line options as long as we don't have a QAPI based config file.

Kevin




reply via email to

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