Btw, the migration_state_notifiers is already there, but seems not really
used (I only tracked spice-core.c called
add_migration_state_change_notifier). I thought adding new migration states
can reuse all that we have.
What's your real concern about that? (not sure how defining new events would
make a difference)
Migration state is exposed via control path (QMP). Adding new states
mean that the QMP clients will see more. IMO that's not really
anything that a QMP client will need to know, instead we can keep it
internally. That's a reason from compatibility pov.
Meanwhile, it's not really a state-thing at all for me. It looks
really more like hook or event (start/stop of sync).
Thanks for sharing your concerns in detail, which are quite helpful for the
discussion. To reuse 99a0db9b, we can also add sub-states (or say events),
instead of new migration states.
For example, we can still define "enum RamSaveState" as above, which can be
an indication for the notifier queued on the 99a0db9b notider_list to decide
whether to call start or stop.
Does this solve your concern?