On Tue, Oct 22, 2024 at 12:37:46PM +0200, Markus Armbruster wrote: > Daniel P. Berrangé <berra...@redhat.com> writes: > > > On Tue, Oct 22, 2024 at 10:41:29AM +0200, Markus Armbruster wrote: > >> Peter Xu <pet...@redhat.com> writes: > >> > >> > Per previous discussion [1,2], this patch deprecates > >> > query-migrationthreads > >> > command. > >> > > >> > To summarize, the major reason of the deprecation is due to no sensible > >> > way > >> > to consume the API properly: > >> > > >> > (1) The reported list of threads are incomplete (ignoring destination > >> > threads and non-multifd threads). > >> > > >> > (2) For CPU pinning, there's no way to properly pin the threads with > >> > the API if the threads will start running right away after > >> > migration > >> > threads can be queried, so the threads will always run on the > >> > default > >> > cores for a short window. > >> > > >> > (3) For VM debugging, one can use "-name $VM,debug-threads=on" instead, > >> > which will provide proper names for all migration threads. > >> > > >> > [1] https://lore.kernel.org/r/20240930195837.825728-1-pet...@redhat.com > >> > [2] https://lore.kernel.org/r/20241011153417.516715-1-pet...@redhat.com > >> > > >> > Signed-off-by: Peter Xu <pet...@redhat.com> > > [...] > > >> > diff --git a/migration/threadinfo.c b/migration/threadinfo.c > >> > index 262990dd75..2867413420 100644 > >> > --- a/migration/threadinfo.c > >> > +++ b/migration/threadinfo.c > >> > @@ -13,6 +13,7 @@ > >> > #include "qemu/osdep.h" > >> > #include "qemu/queue.h" > >> > #include "qemu/lockable.h" > >> > +#include "qemu/error-report.h" > >> > #include "threadinfo.h" > >> > > >> > QemuMutex migration_threads_lock; > >> > @@ -52,6 +53,9 @@ MigrationThreadInfoList > >> > *qmp_query_migrationthreads(Error **errp) > >> > MigrationThread *thread = NULL; > >> > > >> > QEMU_LOCK_GUARD(&migration_threads_lock); > >> > + > >> > + warn_report("Command 'query-migrationthreads' is deprecated"); > >> > >> We don't normally do this for QMP commands. > >> > >> Management applications can use -compat deprecated-input=reject to check > >> they're not sending deprecated commands or arguments. > >> > >> Suggest to drop. > > > > They could, but in practice I don't believe anything is doing this, so > > the warning message is a practical way to alert people to the usage. > > Again, we not normally do this. What makes this one different?
Do we not ? My expectation is that everything we record in deprecated.rst also has a corresponding warn_report / warn_report_once in the code. We know users may not read the docs, so we have a multi-pronged approach to alerting them. > Stepping onto my soapbox: if stuff going away surprisingly would cause > you enough inconvenience to make early warning desirable, testing with > suitable -compat is a lot more reliable than relying on warnings. > *Especially* when your automated testing files warnings unexamined > together with any other crap that may go to stderr, so your best chance > to notice the warning is in ad hoc manual testing of QEMU. Nobody does > that until after things broke. I don't see it as an either or choice. We try to surface the deprecation info in as many different ways as is practical, as no single approach is going to hit all bases. * Document it (deprecated.rst) * Warn on QEMU stderr if used at runtime (warn_report) * Enable apps to validate their usage in tests (-compat) * Mark guests as tainted (libvirt API & VM log file, for certain asepts) With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
