Damien Hedde <damien.hedde@greensocs.com> writes:
> Hi Markus,
>
> It looks promising. I did not think we could so "easily" have a new
> working startup.
Look at this big axe I got! ;)
> But I'm not so sure that I understand how we should
> progress from here.
I neglected to explain this my cover letter. My apologies...
> I see 3 main parts in this:
> A. introducing new binary (meson, ...)
> B. startup api: phase related stuff (maybe more)
> C. cli to qmp parser
Makes sense to me at a high level.
> I think if we want to add a new binary (instead of replace it), there
> will be some common api and every startup will have to
> support/implement it. Probably some part of vl.c will have to go in
> some common code.
> In practice, we probably should introduce/extract this before
> introducing the new binary.
I think there are two practical ways to structure such patches:
* Refactor existing code to make parts available for new code, then
introduce new code that uses them.
* Copy, cut unwanted parts, refactor to deduplicate.
I think either way can work as patches. The second way is how I'd start
the work myself.
> One central part of this api is the phase mechanism (even if legacy
> startup can only support it partially or not-at-all).
>
> I think we have 2 choices:
> + we have to use until_phase explicitly
> + we make qmp commands implicitly advances phases when needed.
Yes.
> I think it's better to go the implicit way as much as possible: it
> means we focus on commands and not on some artificial phases we set up
> because of legacy.
An explicit phase control command looked like the fast & easy path to
phase control to me, so that's what I picked for the RFC.
Instead of a single "advance to arbitrary phase" command, we can have
multiple "do X, which requires phase Y and advances to phase Y+1"
commands. E.g. "create machine" goes from @no-machine to
@machine-created.
We may want additional, automatic phase advances for convenience, but I
feel it's best to get the essential stuff roughly right before talking
about convenience features.
> Either way, we probably should put the phase info in qapi so that we
> don't have to hardcode that in every command in order to have common
> error handling. One thing we could do is replace "allow-preconfig" in
> qapi by some phase requirement entry(entries?) and make qmp call
> qemu_until_phase() or some qemu_phase_check() function.
I'd also like some phase support from QAPI. Manual phase checking code
in commands would be tedious and error prone. Better to declare
required phase(s) in the schema.
One small step further: declare phase transitions in the schema, too.
Then the phase state machine definition is all *data*. Data is easier
to reason about than code. Extracting the complete state machine from
the schema is straightforward. Extracting it from C code is anything
but.
> We also maybe need to sort out if we want to merge the phases into the
> runstate.
Yes.
> Thanks for making the effort to do this rfc,
Thanks for your feedback!