Re: Redesign of QEMU startup & initial configuration

[Markus Armbruster <armbru@redhat.com>]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Fri, Dec 10, 2021 at 04:26:20PM +0100, Markus Armbruster wrote:
>> 
>> The existing binary provides bad CLI and limited QMP.
>> 
>> Going from limited to good QMP involves reworking the startup code.  I
>> believe that's easier in a new binary.
>> 
>> Going from bad CLI to good CLI involves incompatible change.
>> Impractical as long as the CLI is a stable interface.  I believe the
>> sane way out is a new binary.
>> 
>> However, I can't see why we'd want to put a good CLI in the old binary
>> then.  We could just as well put it in the new binary, or in a wrapper
>> program around the new binary.
>
> Having good CLI in a completely new binary is likely to be easier
> for users to understand too. The typical pitfall with our existing
> binaries is that they provide 4 ways to do the same thing, from
> the different points in QEMU's life. This constantly trips up
> unsuspecting users and also makes our docs task way more complicated
> to think about.

I think it's more often just three: the long one that can do everything,
the short one that can do simple things (and doesn't tell you anything
about the long one), and the bad one you shouldn't use.

> If we're going to have a good CLI, it would ideally only have
> one way to do each given task.

Ideally, the long one plus good defaults suffices.

When we must also have a short one, it should macro-expand into long
one(s), and the user should be able to see the expansion.

> No matter what we do we're fighting against a mass of docs
> all over the internet talking about 15 years of old QEMU
> syntax. If we do a good CLI in a newly named binary, at
> least when reading docs, it'll be pretty clear whether
> it is talking about the old QEMU or new QEMU binaries,
> reducing liklihood of mixing things up.

An advantage that truly matters.