On 1/25/22 12:36, Markus Armbruster wrote: > Juan Quintela <quintela@xxxxxxxxxx> 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.
