Peter Xu <pet...@redhat.com> writes: > This reverts two commits: > > 671326201dac8fe91222ba0045709f04a8ec3af4 > 1b1f4ab69c41279a45ccd0d3178e83471e6e4ec1 > > Meanwhile it adds an entry to removed-features.rst for the > query-migrationthreads QMP command. > > This patch originates from another patchset [1] that wanted to cleanup the > interface and add corresponding HMP command, as lots of things are missing > in the query report; so far it only reports the main thread and multifd > sender threads; all the rest migration threads are not reported, including > multifd recv threads. > > As pointed out by Dan in the follow up discussions [1], the API is designed > in an awkward way where CPU pinning may not cover the whole lifecycle of > even the thread being reported. When asked, we also didn't get chance to > hear from the developer who introduced this feature to explain how this API > can be properly used. > > OTOH, this feature from debugging POV isn't very helpful either, as all > these information can be easily obtained by GDB. Esepcially, if with > "-name $VM,debug-threads=on" we do already have names for each migration > threads (which covers more than multifd sender threads). > > So it looks like the API isn't helpful in any form as of now, besides it > only adds maintenance burden to migration code, even if not much. > > Considering that so far there's totally no justification on how to use this > interface correctly, let's remove this interface instead of cleaning it up. > > In this special case, we even go beyond normal deprecation procedure, > because a deprecation process would only make sense when there are existing > users. In this specific case, we expect zero serious users with this API. > > [1] > https://lore.kernel.org/qemu-devel/20240930195837.825728-1-pet...@redhat.com/ > > Cc: Jiang Jiacheng <jiangjiach...@huawei.com> > Signed-off-by: Peter Xu <pet...@redhat.com>
Reviewed-by: Fabiano Rosas <faro...@suse.de>
