Re: [PATCH v3 2/4] usb/hub: mark as deprecated

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Jun 12, 2024 at 04:52:50PM +0100, Alex Bennée wrote:
> Daniel P. Berrangé <berrange@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?

We've got 2 flags proposed in patch 1 - "deprecated" and "not_secure" -
which we formally expose to mgmt apps/users. Both of these are actionable
in an unambiguous way. An application can query this info, and can also
tell QEMU to enforce policy on this. Both are good.

The "better alternatives" conceptable, however, is an inherantly fuzzy
concept, because "better" is very much a use-case depedent / eye of the
beholder concept. This would makes it difficult/impractical for an
application to take action based on such a "better-alternatives' schema
marker. It would imply the application has to understands the better
alternatives ahead of time, as well as understanding the end users'
intent and that's not really viable.



This is a long winded way of saying that while "better alternatives"
is certainly a concept that is relevant, I'm not convinced it belongs
in the schema, as opposed to being a documentation task.

We haven't consistently provided documentation in the manual for every
device, so in many cases '-device help' is all that exists, but in the
case of USB we do actually have docs:

  https://www.qemu.org/docs/master/system/devices/usb.html

and those docs give little guidance to users about 'usb-hub', so IMHO
that's where we should be documenting the tradeoffs of the different
USB config scenarios.

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 :|