qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v7 0/3] 9p: Fix file ID collisions


From: Christian Schoenebeck
Subject: Re: [Qemu-devel] [PATCH v7 0/3] 9p: Fix file ID collisions
Date: Tue, 24 Sep 2019 11:31:06 +0200

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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]