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