From: "Alex Bennée" <alex.bennee@linaro.org>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>,
qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
Eduardo Habkost <eduardo@habkost.net>,
Eric Blake <eblake@redhat.com>
Subject: Re: [PATCH v3 2/4] usb/hub: mark as deprecated
Date: Thu, 13 Jun 2024 15:49:23 +0100 [thread overview]
Message-ID: <8734pgx5ho.fsf@draig.linaro.org> (raw)
In-Reply-To: <ZmrOgxutj7ETndGM@redhat.com> ("Daniel P. Berrangé"'s message of "Thu, 13 Jun 2024 11:48:35 +0100")
Daniel P. Berrangé <berrange@redhat.com> writes:
> On Thu, Jun 13, 2024 at 12:38:31PM +0200, Markus Armbruster wrote:
>> Daniel P. Berrangé <berrange@redhat.com> writes:
>>
>> > On Thu, Jun 13, 2024 at 10:31:56AM +0200, Markus Armbruster wrote:
>> >> Alex Bennée <alex.bennee@linaro.org> writes:
>> >>
>> >> > 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?
>> >>
>> >> 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."
>
> Fair point, but assigning additional meanings to the existing 'deprecation'
> concept will undermine the value QEMU & its consumers obtain from current
> usage.
>
> Consumers know if they see the "deprecated" marker, it has started a clock
> ticking and they must immediately plan work to stop using the feature.
>
> QEMU maintainers know if they see the 'deprecated' marker and it has been
> 2 releases, then we can delete it.
>
> I don't want to loose that clear & easily understood meaning, by overloading
> "deprecated" for scenarios like "it is sometimes better to use a different
> device instead of this one, depending on factors X, Y & Z".
I agree we shouldn't overload the meaning if deprecated.
So to this case in point. Is there anything you can do with usb/hub that
you can't do with the newer xhci based one? Is it backward compatible
enough that an old kernel would work? Or are we talking really old
kernels at this point?
Is there non-PC hardware that utilises these hubs?
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
next prev parent reply other threads:[~2024-06-13 14:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-06 14:30 [PATCH v3 0/4] allow to deprecate objects and devices Gerd Hoffmann
2024-06-06 14:30 ` [PATCH v3 1/4] qom: allow to mark objects as deprecated or not secure Gerd Hoffmann
2024-06-06 14:38 ` Daniel P. Berrangé
2024-06-07 6:24 ` Philippe Mathieu-Daudé
2024-06-12 11:07 ` Markus Armbruster
2024-06-12 11:24 ` Daniel P. Berrangé
2024-06-12 11:44 ` Markus Armbruster
2024-06-06 14:30 ` [PATCH v3 2/4] usb/hub: mark as deprecated Gerd Hoffmann
2024-06-06 14:41 ` Daniel P. Berrangé
2024-06-12 15:52 ` Alex Bennée
2024-06-13 8:31 ` Markus Armbruster
2024-06-13 8:34 ` Daniel P. Berrangé
2024-06-13 10:38 ` Markus Armbruster
2024-06-13 10:48 ` Daniel P. Berrangé
2024-06-13 14:49 ` Alex Bennée [this message]
2024-06-14 7:03 ` Gerd Hoffmann
2024-06-13 8:44 ` Daniel P. Berrangé
2024-06-14 8:40 ` Gerd Hoffmann
2024-06-06 14:30 ` [PATCH v3 3/4] vga/cirrus: mark as not secure Gerd Hoffmann
2024-06-06 14:37 ` Daniel P. Berrangé
2024-06-06 14:30 ` [PATCH v3 4/4] qdev: add device policy [RfC] Gerd Hoffmann
2024-06-06 14:49 ` Peter Maydell
2024-06-12 8:30 ` Markus Armbruster
2024-06-12 11:40 ` [PATCH v3 0/4] allow to deprecate objects and devices Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8734pgx5ho.fsf@draig.linaro.org \
--to=alex.bennee@linaro.org \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=eduardo@habkost.net \
--cc=kraxel@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).