On 8/26/25 21:06, Marc-André Lureau wrote:
Hi
On Tue, Aug 26, 2025 at 10:28 PM Paolo Bonzini <pbonz...@redhat.com
<mailto:pbonz...@redhat.com>> wrote:
On 8/26/25 16:04, marcandre.lur...@redhat.com
<mailto:marcandre.lur...@redhat.com> wrote:
> From: Marc-André Lureau <marcandre.lur...@redhat.com
<mailto:marcandre.lur...@redhat.com>>
>
> This will allow to split vmstate to a standalone crate next.
Can you explain why this is needed? Could "migration" depend on "bql"
(or even, "bql" could stay in util), and keep the implementation of
VMState for cells, just like you do for Opaque?
vmstate doesn't require bql. Why should we enforce it at rust level?
In some sense it does: pre_load/post_load/pre_save/post_save run inside
the BQL. It doesn't require it at the language level, but it does at
the conceptual level.
Anyhow the code is fine, I just wanted to understand if there was
something else.
If we merge bql in util, then sure we can make vmstate keep the VMState
impl for BqlCells. But why should we do that? To save one crate? I think
it will more future proof if we have a lower-level util crate without
bql, and higher-level crates that rely on it. Perhaps "bql" should be
renamed though (qemu-loop/iothread or something?)
I'm okay with keeping bql separate, no problem. event_loop is also okay
as the name.
Paolo
