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