Re: [PULL 51/59] system: Remove deprecated 'debug-threads' option for -name
(Cc'ing migration compat and libvirt teams) On 28/10/26 02:01, Richard Henderson wrote:
On 10/27/26 14:23, Philippe Mathieu-Daudé wrote:
'debug-threads' option for -name was deprecated in v11.0 (commit 1b65aeed2a0 "system: unconditionally enable thread naming") thus can now be removed.
Signed-off-by: Philippe Mathieu-Daudé<philmd@oss.qualcomm.com> Reviewed-by: Pierrick Bouvier<pierrick.bouvier@oss.qualcomm.com> Reviewed-by: Ján Tomko<jtomko@redhat.com> Reviewed-by: Dr. David Alan Gilbert<dave@treblig.org> Message-Id:<20261018232917.7716-1-philmd@oss.qualcomm.com> --- docs/about/deprecated.rst | 7 ------- docs/about/removed-features.rst | 9 +++++++-- system/vl.c | 11 ----------- tests/qtest/migration/framework.c | 4 ++-- tests/qtest/migration/precopy-tests.c | 2 +- qemu-options.hx | 7 +++---- 6 files changed, 13 insertions(+), 27 deletions(-)
You need to remove this from the testsuite as well:
Hmm I was surprised because the pipeline in my fork passed, but then looking clearer this job is marked as "allow_failure: true" for me, why is it blocking on the mainstream repo? Back to the test, this is the migration-compat-x86_64 job running previous release binary vs latest one, so I'd think this is the expected behavior, v11.0 and v11.1 have that deprecated option, and we can not test vs v11.2 which removed it. If we want to change that workflow, then when deprecating on v11.0 we also need to remove the tests coverage, so when we remove the feature at $deprecation_release+2 the migration-compat test does not break. Here the question is, do we want to keep testing deprecated features? Maybe yes in the case of unmaintained area when the deprecation process triggers new maintainers stepping in and the deprecation to be cancelled. We could also mark the feature removed but keep it ignored and undocumented until the next release but we'll likely forget and miss that in workflow so I don't recommend that way. Maybe there are another ways to resolve that but I'm not seeing them. Ideas?
On 10/28/26 02:32, Philippe Mathieu-Daudé wrote:
(Cc'ing migration compat and libvirt teams)
On 28/10/26 02:01, Richard Henderson wrote:
On 10/27/26 14:23, Philippe Mathieu-Daudé wrote:
'debug-threads' option for -name was deprecated in v11.0 (commit 1b65aeed2a0 "system: unconditionally enable thread naming") thus can now be removed.
Signed-off-by: Philippe Mathieu-Daudé<philmd@oss.qualcomm.com> Reviewed-by: Pierrick Bouvier<pierrick.bouvier@oss.qualcomm.com> Reviewed-by: Ján Tomko<jtomko@redhat.com> Reviewed-by: Dr. David Alan Gilbert<dave@treblig.org> Message-Id:<20261018232917.7716-1-philmd@oss.qualcomm.com> --- docs/about/deprecated.rst | 7 ------- docs/about/removed-features.rst | 9 +++++++-- system/vl.c | 11 ----------- tests/qtest/migration/framework.c | 4 ++-- tests/qtest/migration/precopy-tests.c | 2 +- qemu-options.hx | 7 +++---- 6 files changed, 13 insertions(+), 27 deletions(-)
You need to remove this from the testsuite as well:
Hmm I was surprised because the pipeline in my fork passed, but then looking clearer this job is marked as "allow_failure: true" for me, why is it blocking on the mainstream repo?
allow_failure is for unstable things, not things that will reliably fail until they're addressed. The macos job is allow_failure; should we knowingly allow a commit that leaves that broken? r~
On Wed, Oct 28, 2026 at 08:32:20AM +0100, Philippe Mathieu-Daudé wrote:
(Cc'ing migration compat and libvirt teams)
On 28/10/26 02:01, Richard Henderson wrote:
On 10/27/26 14:23, Philippe Mathieu-Daudé wrote:
'debug-threads' option for -name was deprecated in v11.0 (commit 1b65aeed2a0 "system: unconditionally enable thread naming") thus can now be removed.
Signed-off-by: Philippe Mathieu-Daudé<philmd@oss.qualcomm.com> Reviewed-by: Pierrick Bouvier<pierrick.bouvier@oss.qualcomm.com> Reviewed-by: Ján Tomko<jtomko@redhat.com> Reviewed-by: Dr. David Alan Gilbert<dave@treblig.org> Message-Id:<20261018232917.7716-1-philmd@oss.qualcomm.com> --- docs/about/deprecated.rst | 7 ------- docs/about/removed-features.rst | 9 +++++++-- system/vl.c | 11 ----------- tests/qtest/migration/framework.c | 4 ++-- tests/qtest/migration/precopy-tests.c | 2 +- qemu-options.hx | 7 +++---- 6 files changed, 13 insertions(+), 27 deletions(-)
You need to remove this from the testsuite as well:
Hmm I was surprised because the pipeline in my fork passed, but then looking clearer this job is marked as "allow_failure: true" for me, why is it blocking on the mainstream repo?
It isn't blocking on upstream repo, it is allow_failure: true there too. Manual inspection of the job shows it is a real bug though.
Back to the test, this is the migration-compat-x86_64 job running previous release binary vs latest one, so I'd think this is the expected behavior, v11.0 and v11.1 have that deprecated option, and we can not test vs v11.2 which removed it.
If we want to change that workflow, then when deprecating on v11.0 we also need to remove the tests coverage, so when we remove the feature at $deprecation_release+2 the migration-compat test does not break. Here the question is, do we want to keep testing deprecated features? Maybe yes in the case of unmaintained area when the deprecation process triggers new maintainers stepping in and the deprecation to be cancelled.
We could also mark the feature removed but keep it ignored and undocumented until the next release but we'll likely forget and miss that in workflow so I don't recommend that way.
Maybe there are another ways to resolve that but I'm not seeing them. Ideas?
'debug-threads=on' has no relationship to live migration data stream, it merely gives the threads names. Just remove this option from the migration testsuite as it is irrelevant to what is being tested. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
On Wed, Oct 28, 2026 at 09:47:43AM +0000, Daniel P. Berrangé wrote:
On Wed, Oct 28, 2026 at 08:32:20AM +0100, Philippe Mathieu-Daudé wrote:
(Cc'ing migration compat and libvirt teams)
On 28/10/26 02:01, Richard Henderson wrote:
On 10/27/26 14:23, Philippe Mathieu-Daudé wrote:
'debug-threads' option for -name was deprecated in v11.0 (commit 1b65aeed2a0 "system: unconditionally enable thread naming") thus can now be removed.
Signed-off-by: Philippe Mathieu-Daudé<philmd@oss.qualcomm.com> Reviewed-by: Pierrick Bouvier<pierrick.bouvier@oss.qualcomm.com> Reviewed-by: Ján Tomko<jtomko@redhat.com> Reviewed-by: Dr. David Alan Gilbert<dave@treblig.org> Message-Id:<20261018232917.7716-1-philmd@oss.qualcomm.com> --- docs/about/deprecated.rst | 7 ------- docs/about/removed-features.rst | 9 +++++++-- system/vl.c | 11 ----------- tests/qtest/migration/framework.c | 4 ++-- tests/qtest/migration/precopy-tests.c | 2 +- qemu-options.hx | 7 +++---- 6 files changed, 13 insertions(+), 27 deletions(-)
You need to remove this from the testsuite as well:
Hmm I was surprised because the pipeline in my fork passed, but then looking clearer this job is marked as "allow_failure: true" for me, why is it blocking on the mainstream repo?
It isn't blocking on upstream repo, it is allow_failure: true there too. Manual inspection of the job shows it is a real bug though.
Back to the test, this is the migration-compat-x86_64 job running previous release binary vs latest one, so I'd think this is the expected behavior, v11.0 and v11.1 have that deprecated option, and we can not test vs v11.2 which removed it.
If we want to change that workflow, then when deprecating on v11.0 we also need to remove the tests coverage, so when we remove the feature at $deprecation_release+2 the migration-compat test does not break. Here the question is, do we want to keep testing deprecated features? Maybe yes in the case of unmaintained area when the deprecation process triggers new maintainers stepping in and the deprecation to be cancelled.
We could also mark the feature removed but keep it ignored and undocumented until the next release but we'll likely forget and miss that in workflow so I don't recommend that way.
Maybe there are another ways to resolve that but I'm not seeing them. Ideas?
'debug-threads=on' has no relationship to live migration data stream, it merely gives the threads names. Just remove this option from the migration testsuite as it is irrelevant to what is being tested.
We're testing with the old migration-test for compat, so Phil doesn't have an easy way to remove that part: .migration-compat-common: ... # Use the migration-tests from the older QEMU tree. This avoids # testing an old QEMU against new features/tests that it is not # compatible with. - cd build-previous Intentional to avoid new things not working with old QEMU binaries, but then this will be the case things break if we don't have protection of 2-release deprecation (where we could have removed the usage in test cases 2 releases in advance too when deprecating). At least two options I see: (1) for this release, we lose compat protection, we'll need to manually guard it, or (2) we provide some way to script/patch on top of the build-previous/ build before it builds, in this case we only need to remove the string in that test alone. I prefer (2) but I'd apologize in advance I don't have almost any time upstream before forum (replied this one only because I want to raise the point of using old test, in case Fabiano's already in PTO), I'm not sure if someone thinks it worthwhile. Thanks, -- Peter Xu
On Wed, Oct 28, 2026 at 07:54:28AM -0400, Peter Xu wrote:
On Wed, Oct 28, 2026 at 09:47:43AM +0000, Daniel P. Berrangé wrote:
On Wed, Oct 28, 2026 at 08:32:20AM +0100, Philippe Mathieu-Daudé wrote:
(Cc'ing migration compat and libvirt teams)
On 28/10/26 02:01, Richard Henderson wrote:
On 10/27/26 14:23, Philippe Mathieu-Daudé wrote:
'debug-threads' option for -name was deprecated in v11.0 (commit 1b65aeed2a0 "system: unconditionally enable thread naming") thus can now be removed.
Signed-off-by: Philippe Mathieu-Daudé<philmd@oss.qualcomm.com> Reviewed-by: Pierrick Bouvier<pierrick.bouvier@oss.qualcomm.com> Reviewed-by: Ján Tomko<jtomko@redhat.com> Reviewed-by: Dr. David Alan Gilbert<dave@treblig.org> Message-Id:<20261018232917.7716-1-philmd@oss.qualcomm.com> --- docs/about/deprecated.rst | 7 ------- docs/about/removed-features.rst | 9 +++++++-- system/vl.c | 11 ----------- tests/qtest/migration/framework.c | 4 ++-- tests/qtest/migration/precopy-tests.c | 2 +- qemu-options.hx | 7 +++---- 6 files changed, 13 insertions(+), 27 deletions(-)
You need to remove this from the testsuite as well:
Hmm I was surprised because the pipeline in my fork passed, but then looking clearer this job is marked as "allow_failure: true" for me, why is it blocking on the mainstream repo?
It isn't blocking on upstream repo, it is allow_failure: true there too. Manual inspection of the job shows it is a real bug though.
Back to the test, this is the migration-compat-x86_64 job running previous release binary vs latest one, so I'd think this is the expected behavior, v11.0 and v11.1 have that deprecated option, and we can not test vs v11.2 which removed it.
If we want to change that workflow, then when deprecating on v11.0 we also need to remove the tests coverage, so when we remove the feature at $deprecation_release+2 the migration-compat test does not break. Here the question is, do we want to keep testing deprecated features? Maybe yes in the case of unmaintained area when the deprecation process triggers new maintainers stepping in and the deprecation to be cancelled.
We could also mark the feature removed but keep it ignored and undocumented until the next release but we'll likely forget and miss that in workflow so I don't recommend that way.
Maybe there are another ways to resolve that but I'm not seeing them. Ideas?
'debug-threads=on' has no relationship to live migration data stream, it merely gives the threads names. Just remove this option from the migration testsuite as it is irrelevant to what is being tested.
We're testing with the old migration-test for compat, so Phil doesn't have an easy way to remove that part:
.migration-compat-common: ... # Use the migration-tests from the older QEMU tree. This avoids # testing an old QEMU against new features/tests that it is not # compatible with. - cd build-previous
Intentional to avoid new things not working with old QEMU binaries, but then this will be the case things break if we don't have protection of 2-release deprecation (where we could have removed the usage in test cases 2 releases in advance too when deprecating).
At least two options I see: (1) for this release, we lose compat protection, we'll need to manually guard it, or (2) we provide some way to script/patch on top of the build-previous/ build before it builds, in this case we only need to remove the string in that test alone.
Or (3) push a change to -stable branches to remove debug-threads usage from old migration-test and use stable HEAD, not the tagged version. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
participants (4)
-
Daniel P. Berrangé -
Peter Xu -
Philippe Mathieu-Daudé -
Richard Henderson