Hi, > this part actually works. .needed is only evaluated on the sending side. For > the receiving side subsections are optional. Migration doesn't fail if a > subsection isn't loaded. Before I sent this patch series one of the > migration tests was a migration from 6.0.92 to 6.0.92 with one byte in the > command reply queue and 3 bytes in the scancode queue. The migration didn't > fail.
Hmm, ok. If you actually tested it you are probably right. My memory tells me ->needed() is evaluated on both sending and receiving side as the migration data stream does not carry the information whenever a subsection is present or not. But maybe my memories are wrong, or things have changed, I don't follow migration changes that closely. > > If we can't find something we can add a property simliar to the one > > for the extended keyboard state. > > What is the best way to add such a compat property? The ps2 keyboard isn't a > qdev device. I can't just add a property to the device class. Do I have to > add a property to the i8042 and the pl050 device and propagate the property > value with the ps2_kbd_init() call to the PS2KbdState? Yes, I think so. But double-check the migration thing first, if your approach works that is the easier way of course. take care, Gerd