On Mon, Sep 8, 2025 at 1:19 PM Paolo Bonzini <[email protected]> wrote: > > On 9/8/25 12:02, Manos Pitsidianakis wrote: > > Hi Paolo, > > > > I'm not familiar with how migration works under the hood, but this > > data transformation design looks very clean and neat to me. > > Thanks! > > >> Using it is very easy, you can just declare your state like: > >> > >> regs: Migratable<Mutex<MyDeviceRegisters>> > > > > Hm it's a shame we cannot do this with a trait since it requires state > > storage for migration_state. > > Yeah, but a Box is just a single pointer. We need to have an actual > location in memory for the C code to retrieve the pointer.
Oh yeah I got that. I was talking about needing to introduce new wrapper types for fields. > > > A suggestion: we could declare a "mirror" struct to hold > > `migration_state` with a Derive macro. This is what the `rkyv` crate > > does with its `Archive` derive macro and trait > > <https://docs.rs/rkyv/latest/rkyv/trait.Archive.html> > > Nice! I'm not familiar with rkyv but it does look very similar. > > When I tried to clean up the HPET (create HPETRegisters, and replace use > of raw pointers with self_cell to implement self-referential structs), > migration was the big mess, so I hope that this design will fix both > that and Mutex<>. And indeed having a derive macro is very similar to > what I came up with one day later :) while thinking about how HPET could > use it in practice. > > Probably the derive macro would require some changes to the trait, but > the basic idea remains the same. Yes exactly. You could store the migration data in another struct (e.g. `FooDeviceMigrationState`) and use it as a conduit between the device and C migration logic. > > Paolo >
