Peter Xu <[email protected]> writes: > On Sun, Feb 01, 2026 at 07:19:55PM +0300, Vladimir Sementsov-Ogievskiy wrote: >> # @migrate-set-parameters: >> @@ -1004,6 +1005,13 @@ >> # is @cpr-exec. The first list element is the program's filename, >> # the remainder its arguments. (Since 10.2) >> # >> +# @backend-transfer: Enable backend-transfer feature for devices that >> +# supports it. In general that means that backend state and its >> +# file descriptors are passed to the destination in the migraton >> +# channel (which must be a UNIX socket). Individual devices >> +# declare the support for backend-transfer by per-device >> +# backend-transfer option. (Since 11.0) > > I still think it'll be nice to either have "local" in the name of parameter > or at least document it with crystal clear terms. > > I used to suggest fd-passing, but maybe you wanted to emphasize there's > more than fds to be migrated at least for tap? Then it can still be > "local-backend-transfer", because nobody stops a device to transfer backend > states in a remote migration either.. so "backend-transfer" seems to also > work for remote migrations, but it is not. > > Or at least mentioned explicitly in the comment, saying this is a local > migration / upgrade.
Documenting the restriction is a must regardless of naming. The proposed text does document it, but only indirectly: "(which must be a UNIX socket)". Could be improved, I guess. Capturing the restriction in the name might help. But it also makes the name longer. Feels like a matter of taste to me. You guys decide :) > If you could at least update the doc on the locality attribute for the > migration (one way or another..), feel free to take: > > Acked-by: Peter Xu <[email protected]> > > If you decide to rename, that's even better. > > Thanks,
