Re: QEMU API cleanup initiative - Let's chat during the KVM call

[John Snow]

On 10/5/20 9:45 AM, Stefan Hajnoczi wrote:
> On Sat, Oct 03, 2020 at 08:14:11PM -0400, John Snow wrote:
> > I would like to use the KVM call to discuss a roadmap for converting the
> > remaining options to QAPI, what that would take, and who will take ownership
> > for which subsystems/flags. I would like to bring these discussions to KVM
> > Forum and lend serious, dedicated effort to finishing this task.
>
> Subsystem maintainers will need to review these patches. Hopefully many
> of them are willing to do the conversion themselves. Code examples for
> common conversions would help (e.g. QemuOpts to QAPI, strtol() to QAPI,
> etc).

Yes, and this depends on how far exactly we want to go on our first 
conversion pass. The exact point we pick as our first intermediate step 
might determine these common conversions.

QemuOpts might be a reasonable first step, or maybe we want to go all 
the way straight to QAPI.

In a few cases (like -cpu), we probably want to start normalizing the 
way in which models are lookup up and defined; some architectures allow 
you to lowercase the models, or perform other text mapping conversions.

We could start deprecating / standardizing these transformations to try 
and unify the CPU parsing infrastructure which would give us a chance to 
describe it all with one set of rules.

Some of this depends on Markus's existing patches -- He has a series 
from 2018 (IIRC) that attempts a lot of the low-hanging fruit for this 
work, and that might serve as a reasonable basis.

Things to discuss.

> Do error messages need to be preserved? For example, maybe the input
> validation order or the actual error message is different with QAPI and
> that may affect programs that launch QEMU.

It's a good point to talk about.

- Markus considers the platonic ideal of a CLI one in which each flag is 
a configuration directive, and each directive that references another 
directive must appear after the directive in which it references.

- I tend to consider the ideal configuration to be a static object that 
has no inherent order from one key to the next, e.g. a JSON object or 
static flat file that can be used to configure the sysemu.

They're not compatible visions; and they have implications for error 
ordering and messages and so on.

For the meantime, Markus's vision is closer to what QEMU already does, 
so it's likely the winning answer for now and if a conversion to the 
other idea is required at a time later, we'll have to tackle it then. (I 
think.)

It's a good subject of discussion. (Also relevant: if parsing is to 
occur in more than the CLI context, the existing contextual CLI parser 
error system needs to be reworked to avoid monitor-unsafe error calls. 
It's not trivial, I think.)

> Is there any way to detect incompatible command-line changes besides
> running make check? One idea is to run a fuzzer to check if certain
> inputs are accepted by the new/old version but not the other.

That might be interesting. I did some fairly thorough auditing to 
understand what each flag actually accepts at-present, but I don't have 
good experience with any fuzzer such to be able to model that exactly.

I'd be happy to hear about ways we could try to model this. Possibly 
intentionally deprecating things to reduce the size of some of our 
weirder parsers might help the modeling effort, too.

> Stefan

--js