Re: Redesign of QEMU startup & initial configuration

From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Damien Hedde" <damien.hedde@greensocs.com>,
	"Mark Burton" <mark.burton@greensocs.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	qemu-devel@nongnu.org,
	"Mirela Grujic" <mirela.grujic@greensocs.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Subject: Re: Redesign of QEMU startup & initial configuration
Date: Fri, 10 Dec 2021 11:25:55 +0000	[thread overview]
Message-ID: <YbM5Q+gq89rWoPt8@redhat.com> (raw)
In-Reply-To: <fb7e946e-6881-0ea3-d824-99693f938165@redhat.com>

On Fri, Dec 10, 2021 at 09:34:41AM +0100, Paolo Bonzini wrote:
> On 12/9/21 20:11, Daniel P. Berrangé wrote:
> > >     They still need to bootstrap a QMP monitor, and for that, CLI is fine
> > >     as long as it's simple and stable.
> 
> I would go a step further and say that the QMP monitor socket should be
> created by whoever invoked QEMU and passed down via systemd's socket
> activation protocol, with a fallback to stdin/stdout.

That's an interesting idea, firmly relegating any "human friendly"
targetted CLI to a separate program, that in turn invokes this
low level QEMU binary. I do like the simplicity of this and the
strict division of the layers it provides us, as it will help keep
us honest when designing human friendly interfaces.

To be clear, I do think the QEMU project should be delivering a
nice simple human targetted interface, and ideally using the
'/usr/bin/qemu' binary name, and able to deliver users a machines
with a modern hardware config that can evolve over time.

> > > = Appendix: Why further incremental change feels impractical =
> > > 
> > > Crafting a big change in small steps sounds great.  It isn't when we
> > > have to make things worse before they can get better, and every step is
> > > painfully slow because it's just too hard, and the end state we aim for
> > > isn't really what we want.
> > 
> > I can't disagree with this. If we carry on trying to evolve vl.c
> > incrementally we are doomed to be stuck with a horrible starstup
> > process for enternity (or at least as long as I'll still be
> > working as QEMU maintainer).
> 
> ... and if you compare vl.c in 5.2 and now, and consider current vl.c to be
> horrible, my knowedge of English does not include an adjective to describe
> the 5.2 state.  Some incremental work _is_ possible or even necessary, and
> has been done already.

Right, I'm not saying vl.c hasn't improved, but we're never going
to get out of the peculiar historical startup ordering rules we
have today by incremental fixes, without breaking people.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|