Daniel P. Berrangé <berra...@redhat.com> writes: > On Thu, Jun 13, 2024 at 10:31:56AM +0200, Markus Armbruster wrote: >> Alex Bennée <alex.ben...@linaro.org> writes: >> >> > Daniel P. Berrangé <berra...@redhat.com> writes: >> > >> >> On Thu, Jun 06, 2024 at 04:30:08PM +0200, Gerd Hoffmann wrote: >> >>> The hub supports only USB 1.1. When running out of usb ports it is in >> >>> almost all cases the much better choice to add another usb host adapter >> >>> (or increase the number of root ports when using xhci) instead of using >> >>> the usb hub. >> >> >> >> Is that actually a strong enough reason to delete this device though ? >> >> This reads like its merely something we don't expect to be commonly >> >> used, rather than something we would actively want to delete. >> > >> > This does seem quite aggressive because there may be cases when users >> > explicitly want to use old devices. Maybe there is need for a third >> > state (better_alternatives?) so we can steer users away from old command >> > lines they may have picked up from the web to the modern alternative? >> >> What exactly do we mean when we call something deprecated? >> >> For me, it means "you should not normally use this". >> >> Important special case: "because we intend to remove it." > > That's not the special case, it is the regular case - the documented > meaning of 'deprecated' in QEMU. When we deprecate something, it is > a warning that we intend to delete it in 2 releases time.
It's the regular case in QEMU today because we made it so there, by electing to limit deprecation to "because we intend to remove it."
