On Montag, 23. September 2019 18:50:12 CEST Greg Kurz wrote: > > > > If yes, and since that would mean I was the only person ever having > > > > tested > > > > the actual fix, shouldn't --multidevs=remap|forbid better be marked as > > > > experimental (docs and runtime warning) for now? Maybe that would also > > > > anticipate receiving feedback from people actually using it later on. > > > > > > Makes sense. I don't think it is worth having a runtime warning, > > > but I'll turn remap to x-remap and amend the docs. > > > > Mwa, I would like to veto against your "x-remap" plan though. Keep in mind > > I also have to send out a patch for libvirt for this fix. Even I would > > not have read "x" to stand for "experimental". So I would definitely > > favor a runtime warning instead of renaming that parameter. > > Hmmm... I don't see the point in adding a warning for a feature that > is only active if the user explicitly asks for it.
Because many people might be using this option without ever reading the docs, e.g. because of being suggested by copy & paste tutorials or any stack*.com forum. > And, anyway, this > still is an experimental feature, right ? No, it is not a feature. It is still a fix. :) I cannot use 9p without this fix at all, so it is not some optional "feature" for me. x-remap would just make things unnecessarily more complicated without adding anything useful. A warning/info log could be used to motivate people providing feedback and make them clearly aware about their current version still being an experimental fix in their specific qemu version. That warning/info is just a one line change that can easily be dropped at some point in future after this qid fix proofed to be reliable (i.e. from users' feedback and test cases). > Not sure it is time to have > libvirt to support it yet. Most people are using libvirt xml configs instead of calling qemu directly with command line options. So of course I will suggest a libvirt patch as soon as this patch set is pulled on qemu side.
