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? > If you need phone number details, contact me privately > > Thanks, Juan.
