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: Kevin Wolf
Subject: Re: Making QEMU easier for management tools and applications
Date: Mon, 27 Jan 2020 13:13:11 +0100
User-agent: Mutt/1.12.1 (2019-06-15)

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 flags.
> 
> Hmm.  Given that the transition effort will probably take a while
> I think it makes sense to allow mixing config file and cmd line
> switches, if it is only for testing the config file parsing and
> processing.  Maybe have a (temporary) -x-config for that?
> 
> 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. Markus and I are trying to use mostly QAPIfied command line
options for qemu-storage-daemon, and --chardev is one that we agree must
be simplified to be bearable.

> The most tricky part here probably is -device support.

Possibly, though -object might not be much easier.

> > - We WOULD need a new YAML parsing layer in QEMU, generated by QAPI.
> > Supporting two deserialization layers could lead to strange
> > discrepancies between the two formats at runtime. So, admittedly, using
> > JSON would be *even easier*, as we could re-use the same parsers already
> > battle-tested in QEMU. We could get *MAXIMUM* code re-use this way.
> 
> Well, we can support multiple formats, much like openshift accepts both
> json and yaml.  json is pretty much there already, so we could start
> with that and add yaml later on.  Possibly even the ini-style syntax
> accepted by -readconfig today, although I'm not sure there is much
> benefit in that.
> 
> > - We will break compatibility with our existing CLI. People will not be
> > happy about this, especially, perhaps, embedded board and TCG developers
> > who use fairly minimal command lines regularly.
> 
> Once config file support is complete enough we should be able to offload
> backward compatibility command line parsing to some script which
> transforms the cli into a config file.  Which is probably better than
> trying to add -writeconfig to qemu as we don't have to do the string
> processing in C then.

If we get a launcher script anyway, I would argue that the system
emulator binary written in C should only support JSON (like it already
does) and the script can easily translate from YAML to JSON.

Kevin




reply via email to

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