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: Greg Kurz
Subject: Re: [Qemu-devel] [PATCH v7 0/3] 9p: Fix file ID collisions
Date: Mon, 23 Sep 2019 18:50:12 +0200

On Mon, 23 Sep 2019 17:03:23 +0200
Christian Schoenebeck <address@hidden> wrote:

> On Montag, 23. September 2019 16:46:53 CEST Greg Kurz wrote:
> > > > > > I'll do some
> > > > > > more manual testing and issue a PR when I'm confident enough.
> > > > > 
> > > > > That would be highly appreciated! So far I am the only one ever having
> > > > > tested this patch set at all!
> > > > 
> > > > Just to clarify, I won't thoroughly test it. My main concern is that it
> > > > doesn't break things.
> > > 
> > > So in other words you are only going to test the default behaviour
> > > --multidevs=warn?
> > 
> > This I've already done, along with multidevs=forbid.
> > 
> > Now I plan to run the PJD test suite from Tuxera with a simple
> > cross-device setup and --multidevs=remap. And that's it.
> 
> Well, Ok then, however at least some simple, manual, final "ls -i" of the 
> inode numbers on guest would not hurt though. ;-)
> 
> > > 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. And, anyway, this
still is an experimental feature, right ? Not sure it is time to have
libvirt to support it yet.

Maybe Daniel can comment on libvirt adoption of new features ?

> I can send a patch on top for docs and warning if you want.
> 
> 




reply via email to

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