"Richard W.M. Jones" writes:
> Sorry for very delayed reply ...
>
> On Thu, Dec 02, 2021 at 07:57:38AM +0100, Markus Armbruster wrote:
>> 1. QMP only
>>
>>Management applications need to use QMP for monitoring anyway. They
>>may want to use it for initial configuration, too. Libvirt do
Sorry for very delayed reply ...
On Thu, Dec 02, 2021 at 07:57:38AM +0100, Markus Armbruster wrote:
> 1. QMP only
>
>Management applications need to use QMP for monitoring anyway. They
>may want to use it for initial configuration, too. Libvirt does.
>
>They still need to bootstrap
>>
>> Totally agree on this (of course).
>>
>> Thats why I’m here - I care about the people who care about emulation :-)
>>
>> In general, what we are working on is exactly the ability to service the
>> ‘complex’ emulation use case. No CLI, nor single ‘config’ file will be good
>> enough,
On Thu, Dec 16, 2021 at 05:00:55PM +0100, Mark Burton wrote:
>
>
> > On 16 Dec 2021, at 16:40, Daniel P. Berrangé wrote:
> >
> > On Thu, Dec 16, 2021 at 04:28:29PM +0100, Paolo Bonzini wrote:
> >> On 12/16/21 11:24, Markus Armbruster wrote:
> Not really, in particular the startup has been
> On 16 Dec 2021, at 16:40, Daniel P. Berrangé wrote:
>
> On Thu, Dec 16, 2021 at 04:28:29PM +0100, Paolo Bonzini wrote:
>> On 12/16/21 11:24, Markus Armbruster wrote:
Not really, in particular the startup has been mostly reworked already
and I disagree that it is messy. softmmu/vl.
On Thu, Dec 16, 2021 at 04:28:29PM +0100, Paolo Bonzini wrote:
> On 12/16/21 11:24, Markus Armbruster wrote:
> > > Not really, in particular the startup has been mostly reworked already
> > > and I disagree that it is messy. softmmu/vl.c is messy, sure: it has
> > > N different command line parser
On 12/16/21 11:24, Markus Armbruster wrote:
Not really, in particular the startup has been mostly reworked already
and I disagree that it is messy. softmmu/vl.c is messy, sure: it has
N different command line parser for command line options, magic
related to default devices, and complicated orde
Paolo Bonzini writes:
> On 12/14/21 12:48, Markus Armbruster wrote:
>> Let's start with where we (hopefully) agree:
>
> More or less I do agree with this, except for a couple points below
> where I think we disagree.
>
>> * We need a single, cohesive, low-level interface suitable for
>> managem
FWIW I Agree.
(Which probably means somethings hiding somewhere :-) )
Cheers
Mark.
> On 15 Dec 2021, at 21:00, Paolo Bonzini wrote:
>
> On 12/14/21 12:48, Markus Armbruster wrote:
>> Let's start with where we (hopefully) agree:
>
> More or less I do agree with this, except for a couple poin
On 12/14/21 12:48, Markus Armbruster wrote:
Let's start with where we (hopefully) agree:
More or less I do agree with this, except for a couple points below
where I think we disagree.
* We need a single, cohesive, low-level interface suitable for
management applications.
* The existing
On 12/13/21 19:53, Daniel P. Berrangé wrote:
Adding vhost-user backends and helper processes means one of two things:
either you are not going to support hotplug, or you are going to redo
libvirtd with a QMP-based RPC.
If it were possible to keep auto-spawning of helpers at the high level
that
On Wed, Dec 15, 2021 at 07:46:37PM +0100, Paolo Bonzini wrote:
> On 12/13/21 19:53, Daniel P. Berrangé wrote:
> > > Adding vhost-user backends and helper processes means one of two things:
> > > either you are not going to support hotplug, or you are going to redo
> > > libvirtd with a QMP-based RP
> On 14 Dec 2021, at 16:12, Markus Armbruster wrote:
>
> Daniel P. Berrangé writes:
>
>> On Tue, Dec 14, 2021 at 03:42:52PM +0100, Mark Burton wrote:
>>> I think we’re talking at cross purposes, and probably we agree (not sure).
>>> I’ll top quote to try and explain my point of view.
>>>
>
Daniel P. Berrangé writes:
> On Tue, Dec 14, 2021 at 03:42:52PM +0100, Mark Burton wrote:
>> I think we’re talking at cross purposes, and probably we agree (not sure).
>> I’ll top quote to try and explain my point of view.
>>
>> I think there are two discussions being mixed:
>> 1/ A discussion
On Tue, Dec 14, 2021 at 03:42:52PM +0100, Mark Burton wrote:
> I think we’re talking at cross purposes, and probably we agree (not sure).
> I’ll top quote to try and explain my point of view.
>
> I think there are two discussions being mixed:
> 1/ A discussion about improving the CLI. (Having a n
Mark Burton writes:
>> On 14 Dec 2021, at 12:48, Markus Armbruster wrote:
>>
>> Paolo Bonzini writes:
>>
>>> On 12/13/21 16:28, Markus Armbruster wrote:
Paolo Bonzini writes:
> On 12/10/21 14:54, Markus Armbruster wrote:
>> I want an open path to a single binary. Taking y
I think we’re talking at cross purposes, and probably we agree (not sure). I’ll
top quote to try and explain my point of view.
I think there are two discussions being mixed:
1/ A discussion about improving the CLI. (Having a new one, etc etc)
2/ A discussion about supporting a low level, and comp
On Tue, Dec 14, 2021 at 02:36:26PM +0100, Mark Burton wrote:
>
>
> > On 14 Dec 2021, at 14:21, Daniel P. Berrangé wrote:
> >
> > On Tue, Dec 14, 2021 at 02:11:11PM +0100, Mark Burton wrote:
> >>
> >>
> >>> On 14 Dec 2021, at 14:05, Daniel P. Berrangé wrote:
> >>>
> >>> On Mon, Dec 13, 2021
> On 14 Dec 2021, at 14:21, Daniel P. Berrangé wrote:
>
> On Tue, Dec 14, 2021 at 02:11:11PM +0100, Mark Burton wrote:
>>
>>
>>> On 14 Dec 2021, at 14:05, Daniel P. Berrangé wrote:
>>>
>>> On Mon, Dec 13, 2021 at 09:22:14PM +0100, Mark Burton wrote:
> On 13 Dec 2021, at 18:
On Tue, Dec 14, 2021 at 02:11:11PM +0100, Mark Burton wrote:
>
>
> > On 14 Dec 2021, at 14:05, Daniel P. Berrangé wrote:
> >
> > On Mon, Dec 13, 2021 at 09:22:14PM +0100, Mark Burton wrote:
> >>
> >>
> >>> On 13 Dec 2021, at 18:59, Daniel P. Berrangé wrote:
> >>>
> >>> …. we no longer have
> On 14 Dec 2021, at 14:05, Daniel P. Berrangé wrote:
>
> On Mon, Dec 13, 2021 at 09:22:14PM +0100, Mark Burton wrote:
>>
>>
>>> On 13 Dec 2021, at 18:59, Daniel P. Berrangé wrote:
>>>
>>> …. we no longer have to solve everything
>>> Ourselves.
>>
>> I support this sentiment.
>>
>> Lets
On Mon, Dec 13, 2021 at 09:22:14PM +0100, Mark Burton wrote:
>
>
> > On 13 Dec 2021, at 18:59, Daniel P. Berrangé 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.
> On 14 Dec 2021, at 12:48, Markus Armbruster wrote:
>
> Paolo Bonzini writes:
>
>> On 12/13/21 16:28, Markus Armbruster wrote:
>>> Paolo Bonzini writes:
>>>
On 12/10/21 14:54, Markus Armbruster wrote:
> I want an open path to a single binary. Taking years to get there is
> f
Paolo Bonzini writes:
> On 12/13/21 16:28, Markus Armbruster wrote:
>> Paolo Bonzini writes:
>>
>>> On 12/10/21 14:54, Markus Armbruster wrote:
I want an open path to a single binary. Taking years to get there is
fine.
>>>
>>> The single binary is a distraction in my opinion. Imagin
> On 13 Dec 2021, at 18:59, Daniel P. Berrangé 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
inte
On Mon, Dec 13, 2021 at 07:37:49PM +0100, Paolo Bonzini wrote:
> On 12/13/21 19:07, Daniel P. Berrangé wrote:
> >- /usr/bin/qemu (or /usr/bin/qemu-vm) - for a high level binary that
> > targets humans and uses a templating system to expose a friendly
> > simple config, that internally
On 12/13/21 19:07, Daniel P. Berrangé wrote:
- /usr/bin/qemu (or /usr/bin/qemu-vm) - for a high level binary that
targets humans and uses a templating system to expose a friendly
simple config, that internally invokes whichever target specific
/usr/bin/qemu-buildvm-$TARGET is im
On Mon, Dec 13, 2021 at 06:37:44PM +0100, Paolo Bonzini wrote:
> On 12/13/21 16:28, Markus Armbruster wrote:
> > Would you object to me expanding the CLI here to the point where I think
> > we can deprecate the old binary?
> >
> > If yes, why?
>
> Yes, for two reasons.
>
> First, because there w
On Mon, Dec 13, 2021 at 06:30:45PM +0100, Paolo Bonzini wrote:
> On 12/13/21 16:19, Markus Armbruster wrote:
> > 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 o
On 12/13/21 16:28, Markus Armbruster wrote:
Paolo Bonzini writes:
On 12/10/21 14:54, Markus Armbruster wrote:
I want an open path to a single binary. Taking years to get there is
fine.
The single binary is a distraction in my opinion. Imagine
instead of vl.c you have this in your second b
On 12/13/21 16:19, Markus Armbruster wrote:
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
Damien Hedde writes:
[...]
>> Painted with a big brush, there are two kinds of code in hw/: actual
>> device emulation, and "wiring". Both in C, and sometimes in the same .c
>> file.
>>
>> Doing the "wiring" in configuration instead is less powerful (no longer
>> Turing complete[2]), but easi
Paolo Bonzini writes:
> On 12/10/21 14:54, Markus Armbruster wrote:
>> I want an open path to a single binary. Taking years to get there is
>> fine.
>
> The single binary is a distraction in my opinion. Imagine
> instead of vl.c you have this in your second binary:
[...]
> static void open_so
Daniel P. Berrangé 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 ba
On 12/10/21 14:54, Markus Armbruster wrote:
Daniel P. Berrangé writes:
On Thu, Dec 02, 2021 at 07:57:38AM +0100, Markus Armbruster wrote:
= Motivation =
QEMU startup and initial configuration were designed many years ago for
a much, much simpler QEMU. They have since changed beyond recog
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 incompatibl
On 12/10/21 14:54, Markus Armbruster wrote:
I want an open path to a single binary. Taking years to get there is
fine.
The single binary is a distraction in my opinion. Imagine
instead of vl.c you have this in your second binary:
/*
* This copyright line means that at some point the below a
Paolo Bonzini writes:
> 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 QEM
On 12/10/21 12:25, Daniel P. Berrangé wrote:
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
> On 10 Dec 2021, at 15:26, Daniel P. Berrangé wrote:
>
> On Fri, Dec 10, 2021 at 03:15:50PM +0100, Mark Burton wrote:
>>
>>
>>> On 10 Dec 2021, at 12:25, Daniel P. Berrangé wrote:
>>>
>>> On Fri, Dec 10, 2021 at 09:34:41AM +0100, Paolo Bonzini wrote:
On 12/9/21 20:11, Daniel P. Berra
On Fri, Dec 10, 2021 at 03:15:50PM +0100, Mark Burton wrote:
>
>
> > On 10 Dec 2021, at 12:25, Daniel P. Berrangé wrote:
> >
> > 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,
> On 10 Dec 2021, at 12:25, Daniel P. Berrangé wrote:
>
> 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.
>>
>
Daniel P. Berrangé writes:
> On Thu, Dec 02, 2021 at 07:57:38AM +0100, Markus Armbruster wrote:
>> = Motivation =
>>
>> QEMU startup and initial configuration were designed many years ago for
>> a much, much simpler QEMU. They have since changed beyond recognition
>> to adapt to new needs. The
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 socke
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 soc
On Thu, Dec 09, 2021 at 09:01:24PM +0100, Mark Burton wrote:
> I’ll take the liberty to cut one part (I agree with much of what you say
> elsewhere)
>
> > On 9 Dec 2021, at 20:11, Daniel P. Berrangé wrote:
> >
> > As illustrated earlier, I'd really like us to consider being a bit
> > more adven
I’ll take the liberty to cut one part (I agree with much of what you say
elsewhere)
> On 9 Dec 2021, at 20:11, Daniel P. Berrangé wrote:
>
> As illustrated earlier, I'd really like us to consider being a bit
> more adventurous on the CLI side. I'm convinced that a CLI for
> directly configurabl
On Thu, Dec 02, 2021 at 07:57:38AM +0100, Markus Armbruster wrote:
> = Motivation =
>
> QEMU startup and initial configuration were designed many years ago for
> a much, much simpler QEMU. They have since changed beyond recognition
> to adapt to new needs. There was no real redesign. Adaption t
= Motivation =
QEMU startup and initial configuration were designed many years ago for
a much, much simpler QEMU. They have since changed beyond recognition
to adapt to new needs. There was no real redesign. Adaption to new
needs has become more and more difficult. A recent example for
"diffic
49 matches
Mail list logo
