Daniel P. Berrangé <[email protected]> writes: > 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 ?
The arguments it exposes aren't really going to change. All it does is allow you simulate what the boilerplate sets in stone. > 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. IMHO no I don't think it would be a burden. > > If exposing the device has minimal burden anticipated on future work, > then no need to mark it experimental > > With regards, > Daniel -- Alex Bennée Virtualisation Tech Lead @ Linaro
