Re: KVM call for agenda for 2022-01-25

[Philippe Mathieu-Daudé]

On 1/25/22 12:36, Markus Armbruster wrote:
> Juan Quintela <quintela@redhat.com> writes:
> 
>> Hi
>>
>> Please, send any topic that you are interested in covering.
>>
>> This week we have a continuation of 2 weeks ago call to discuss how to
>> enable creation of machines from QMP sooner on the boot.
>>
>> There was already a call about this 2 weeks ago where we didn't finished
>> everything.
>> I have been on vacation last week and I haven't been able to send a
>> "kind of resume" of the call.
>>
>> Basically what we need is:
>> - being able to create machines sooner that we are today
>> - being able to change the devices that are in the boards, in
>>   particular, we need to be able to create a board deciding what devices
>>   it has and how they are connected without recompiling qemu.
>>   This means to launch QMP sooner that we do today.
>> - Several options was proposed:
>>   - create a new binary that only allows QMP machine creation.
>>     and continue having the old command line
>>   - create a new binary, and change current HMP/command line to just
>>     call this new binary.  This way we make sure that everything can be
>>     done through QMP.
>>   - stay with only one binary but change it so we can call QMP sooner.
>> - There is agreement that we need to be able to call QMP sooner.
>> - There is NO agreement about how the best way to proceed:
>>   * We don't want this to be a multiyear effort, i.e. we want something
>>     that can be used relatively soon (this means that using only one
>>     binary can be tricky).
>>   * If we start with a new binary that only allows qmp and we wait until
>>     everything has been ported to QMP, it can take forever, and during
>>     that time we have to maintain two binaries.
>>   * Getting a new binary lets us to be more agreessive about what we can
>>     remove/change. i.e. easier experimentation.
>>   * Management Apps will only use QMP, not the command line, or they
>>     even use libvirt and don't care at all about qemu.  So it appears
>>     that HMP is only used for developers, so we can be loose about
>>     backwards compatibility. I.e. if we allow the same functionality,
>>     but the syntax is different, we don't care.
>>
>> Discussion was longer, but it was difficult to take notes and as I said,
>> the only thing that appears that everybody agrees is that we need an
>> agreement about what is the plan to go there.
>>
>> After discussions on the QEMU Summit, we are going to have always open a
>> KVM call where you can add topics.
>>
>>  Call details:
>>
>> By popular demand, a google calendar public entry with it
>>
>>   
>> https://www.google.com/calendar/embed?src=dG9iMXRqcXAzN3Y4ZXZwNzRoMHE4a3BqcXNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ
>>
>> (Let me know if you have any problems with the calendar entry.  I just
>> gave up about getting right at the same time CEST, CET, EDT and DST).
> 
> https://wiki.qemu.org/Contribute claims the call is at
> 
>     $ date -d 'TZ="America/New_York" Tuesday 10:00 am'
>     Tue Jan 25 16:00:00 CET 2022
> 
> Is that correct?

This was incorrect and now fixed, thanks!

Phil.