qemu-devel
[Top][All Lists]
Advanced

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

Re: Redesign of QEMU startup & initial configuration


From: Mark Burton
Subject: Re: Redesign of QEMU startup & initial configuration
Date: Mon, 13 Dec 2021 21:22:14 +0100



On 13 Dec 2021, at 18:59, Daniel P. Berrangé <berrange@redhat.com> wrote:

…. we no longer have to solve everything
Ourselves. 

I support this sentiment.

Lets re-factor the code so people can build what they need using an API.
Actually, ‘QEMU’ only need support the existing CLI, and provide a suitable internal API.
If that API was relatively stable, that would help those (few) who maintain a different startup mechanism (but its only a ’nice to have’). (Making that convenient, as Paolo has show, would also be ’nice to have’).

If Paolo (sorry to pick on you :-) ) wants a pink spotted dog, then - surely - let him have it. YES it’s a separate binary. YES it has a different CLI…. So what? It has nothing to do with QEMU itself, Paolo can maintain it, out of the QEMU tree. QEMU should not attempt to directly support all use cases -  those who have the use case should support them. (e.g. We should not be arguing about what JSON parsing mechanism to use, how command lines could be better,  or configuration languages - thats for the use case provider to worry about. )

That leaves us needing a ‘full’ API. Surely we should be arguing about that - what “full” means, how the QAPI should work, specifically how phases should work, etc. How to move QAPI forward.

To help, I do think it’s important that we include use cases into QEMU (as it stands) in order to build test cases and to effectively have the use cases coded; but only as a ’step’. The plan to refactor needs to be there from the start. [Once refactored, ‘unstable’ features used to demonstrate use cases can be removed of course]

Of course, ‘Refactoring the code’ and getting the CLI to work with the ‘new’ QAPI will be hard  - but each and every scheme I’ve seen so far has some pain involved. If we know this is the goal, then we can start planning how to get there. (And GreenSocs will commit to help if we can).

(Of course, one day, a ‘use case provider’ might come along with the best CLI ever, and the best config language ever, and we will all bow down and use it…. Until that day…. Can we focus on the key for QEMU, providing a ‘full’ QAPI tat can support all use cases (and the existing CLI)).

Cheers
Mark.


reply via email to

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