On Tue, 28 Mar 2017 12:14:59 +0200
Cornelia Huck <cornelia.h...@de.ibm.com> wrote:

> On Tue, 28 Mar 2017 11:34:15 +0200
> Greg Kurz <gr...@kaod.org> wrote:
> 
> > On Tue, 28 Mar 2017 10:24:21 +0200
> > Cornelia Huck <cornelia.h...@de.ibm.com> wrote:
> >   
> > > On Tue, 28 Mar 2017 10:14:09 +0200
> > > Greg Kurz <gr...@kaod.org> wrote:
> > >   
> > > > On Mon, 27 Mar 2017 21:20:56 +0300
> > > > "Michael S. Tsirkin" <m...@redhat.com> wrote:
> > > >     
> > > > > On Mon, Mar 27, 2017 at 07:46:03PM +0200, Greg Kurz wrote:    
> > > > > > This introduces an Error object based implementation of 
> > > > > > virtio_error(). It
> > > > > > allows to implement virtio_error() wrappers in device-specific code.
> > > > > > 
> > > > > > Signed-off-by: Greg Kurz <gr...@kaod.org>
> > > > > > ---
> > > > > >  hw/virtio/virtio.c         |   21 ++++++++++++++++-----
> > > > > >  include/hw/virtio/virtio.h |    1 +
> > > > > >  2 files changed, 17 insertions(+), 5 deletions(-)
> > > > > >     
> > >   
> > > > > Also, whether to stop the device, or the VM, or just warn,
> > > > > seems like a policy decision. Why not set it on command line
> > > > > like we do for other storage?
> > > > >     
> > > > 
> > > > Huh? This patch simply introduces a new API to a feature that underwent
> > > > several rounds of discussion and reached a reasonable consensus (even
> > > > your R-b).
> > > > 
> > > > I'm not sure this 9pfs series is the right place to talk about all the
> > > > behavior changes you're suggesting for virtio_error()... I'd rather
> > > > drop this patch and duplicate code in virtio-9p instead if I want the
> > > > fixes to go to 2.9.    
> > > 
> > > I agree that we should discuss this outside of this patch series. It's
> > > not like it is introducing a new error case.
> > >   
> > > > 
> > > > Cc'ing Connie and Stefanha for insights.    
> > > 
> > > See my reply to Michael's mail.
> > >   
> > 
> > Yeah, I saw that just after pressing the send button :)  
> 
> :)
> 
> > 
> > The points raised by Michael make a lot of sense anyway. Maybe we can
> > discuss them for 2.10 ?  
> 
> Certainly. We should not delay any fixes for 2.9, though.
> 

Michael,

Your comments call for some more discussion to take place during 2.10 devel.

Can you please ack this patch and I'll take it through my tree for 2.9 ?

Cheers.

--
Greg

Attachment: pgpDfeIhrAuDr.pgp
Description: OpenPGP digital signature

Reply via email to