qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
	"Christian Speich" <c.speich@avm.de>,
	qemu-devel@nongnu.org, "Stefano Garzarella" <sgarzare@redhat.com>
Subject: Re: [PATCH] virtio: vhost-user-device: Make user creatable again
Date: Thu, 9 Oct 2025 11:20:10 +0100	[thread overview]
Message-ID: <aOeMWq_RbN8lLwSk@redhat.com> (raw)
In-Reply-To: <20251004133102-mutt-send-email-mst@kernel.org>

On Sat, Oct 04, 2025 at 01:33:48PM -0400, Michael S. Tsirkin wrote:
> On Mon, Sep 29, 2025 at 11:07:06AM +0100, Daniel P. Berrangé wrote:
> > > Well that's because e.g. kvmtest actually depends on pci-testdev.
> > > IOW it's actually supported.
> > 
> > This again just sounds like a downstream 'support' rationalization.
> > I'm still not seeing a compelling reason why the vhost user generic
> > device should be disabled by default in upstream, especially if we
> > mark it as an experimental device with an x- prefix. 
> 
> We can do that. I am still somewhat puzzled by whether making
> it unsupported/experimental addresses the actual need, which
> seems to be to expose it to end users?

My interpretation is that simply having the device exist by default
in QEMU builds is the minimum bar. If we declare it supported, then
that is a "nice to have"  guarantee for long term.

> Once something is used in the field, we can't take it back
> whether we added x- to the name or not.
> 
> What are your thoughts if it's not marked as experimental?

In general my view is that we can't protect against user foolishness.
If they provide inappropriate configuration options to this device
and get broken behaviour, so be it.  If they file bugs against QEMU
our assistance will be very minimal - they get to do the debugging.

On our side as maintainers, the important question is whether exposing
this device ties our hands for future code development.

eg would it unacceptably limit our ability to refactor things in future,
while keeping compat for this exposed device ?

If it would be an undue burden, then it would be worth marking it as
experimental to give us the freedom to make incompatible changes.

If exposing the device has minimal burden anticipated on future work,
then no need to mark it experimental

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



  reply	other threads:[~2025-10-09 10:21 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-19 14:30 [PATCH] virtio: vhost-user-device: Make user creatable again Christian Speich
2025-09-19 14:46 ` Stefano Garzarella
2025-09-19 20:07 ` Michael S. Tsirkin
2025-09-22 10:40   ` Christian Speich via
2025-09-22 10:56     ` Michael S. Tsirkin
2025-09-22 11:11       ` Christian Speich via
2025-09-22 14:37         ` Michael S. Tsirkin
2025-09-25  7:56           ` Christian Speich
2025-09-25  9:33             ` Michael S. Tsirkin
2025-09-25 10:14               ` Christian Speich
2025-09-22 11:33   ` Daniel P. Berrangé
2025-09-22 12:15     ` Michael S. Tsirkin
2025-09-22 12:49       ` Daniel P. Berrangé
2025-09-22 13:08         ` Michael S. Tsirkin
2025-09-22 13:26           ` Christian Speich via
2025-09-22 13:30             ` Michael S. Tsirkin
2025-09-22 13:42               ` Christian Speich
2025-09-22 15:14               ` Alex Bennée
2025-09-29  8:12                 ` Christian Speich
2025-09-29  8:22                 ` Daniel P. Berrangé
2025-09-29  8:24                   ` Michael S. Tsirkin
2025-09-29  9:52                     ` Alex Bennée
2025-09-29 10:07                     ` Daniel P. Berrangé
2025-10-04 17:33                       ` Michael S. Tsirkin
2025-10-09 10:20                         ` Daniel P. Berrangé [this message]
2025-10-09 16:49                           ` Alex Bennée
2025-09-22 12:51     ` Alex Bennée
2025-09-22 13:33     ` Christian Speich
2025-09-22 14:38       ` Daniel P. Berrangé

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=aOeMWq_RbN8lLwSk@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=c.speich@avm.de \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=sgarzare@redhat.com \
    /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).