Re: [PATCH v2 10/10] migration: Switch to TYPE_OBJECT with object properties
Peter Xu <[email protected]> Wed, 10 Jun 2026 14:51:23 -0400
| Newsgroups | org.nongnu.qemu-rust,org.nongnu.qemu-arm,org.nongnu.qemu-devel |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Jun 10, 2026 at 05:29:59PM +0100, Daniel P. Berrangé wrote: > -global is/was intended for devices, primarily those which > are created by default as part of the machine. For dynamically > created devices the docs recommend use of -device instead > of -global. I wished it was called -device-global then it'll be clearer, otherwise from an API perspective it really shouldn't be limited to qdev.. It makes sense to not call it -device-global, IMHO essentially because we don't necessarily need to restrict it to -device. > > I get that -global was exposed for migration via the inappropriate > use of TYPE_DEVICE as a parent for TYPE_MIGRATION, but I don't > think we should be prolonging that misuse by exposing use of > -global for things which are QOM rather than QDev. > > If we want todo that for the sake of backcompat, IMHO it should > be deprecated so it only lives for a short while after the > conversion to QOM. > > This makes me realize that this does not implement the UserCreatable > interface on TYPE_MIGRATION, so I'm presuming the MigrationState is > still created internally. Perhaps we should switch to making it a > full UserCreatable, such that -object can be used to set all migration > parameters on the command line and -global won't be required ? This is what Fabiano suggested in his reply here: https://lore.kernel.org/qemu-devel/[email protected]/ I wonder what's your view on that when put together the singleton series I used to post, where I also mentioned in the reply: https://lore.kernel.org/qemu-devel/[email protected]/ If you think that's the right approach, we can try to have it to replace -global. -global is debug API for migration, we don't need to obsolete it. Compat property is, which is unaffected by this. So we can remove -global support for migration, but it'll always be good to have a replacement for scripts. Thanks, -- Peter Xu