Re: [Qemu-devel] [PATCH 3/3] block/stream.c: ensure copy always set

2013-09-25 Thread Stefan Hajnoczi 
On Tue, Sep 24, 2013 at 03:27:49PM +0100, Alex Bennée wrote:
 
 stefa...@redhat.com writes:
 
  On Mon, Sep 23, 2013 at 05:07:30PM +0100, alex.ben...@linaro.org wrote:
  From: Alex Bennée a...@bennee.com
  
  This only showed up when compiling with
  --enable-trace-backend=stderr|ftrace at which point the compiler
  complains with the following:
 nsip
 
  Stefan Weil already posted a similar patch:
  http://patchwork.ozlabs.org/patch/276936/
 
 OK I'll drop the patch in v3 which I guess is getting ready to be a
 proper PULL request ;-)

You don't need to send a pull request yourself.  Once your patch is
reviewed it should be merged by a maintainer.

 What's the typical lag for trivial patches getting in? I see there are
 periodic trivial pull requests. I assume there are maintainers that
 collect these up into trees?

Contributors send patches to qemu-devel.  After the patches are reviewed
they are merged either directly into qemu.git or into a subsystem tree
by a maintainer.

Subsystem maintainers send pull requests to flush their patch queue when
they feel it is appropriate.  For example, Kevin and I send a weekly
block layer pull request that usually contains 5-15 patches.

Expect 1.5 weeks to get the average patch reviewed and merged into
qemu.git.  If you're lucky they can be merged in a day.  If you're
unlucky you may have to ping the list to move the process along.

Stefan

Re: [Qemu-devel] [PATCH 3/3] block/stream.c: ensure copy always set

2013-09-24 Thread Stefan Hajnoczi 
On Mon, Sep 23, 2013 at 05:07:30PM +0100, alex.ben...@linaro.org wrote:
 From: Alex Bennée a...@bennee.com
 
 This only showed up when compiling with
 --enable-trace-backend=stderr|ftrace at which point the compiler
 complains with the following:
 
 block/stream.c: In function ‘stream_run’:
 block/stream.c:141:22: error: ‘copy’ may be used uninitialized in this 
 function [-Werror=uninitialized]
 
 Not sure exactly why it needs these options but it does seem clear the
 negative return case should be handled.
 ---
  block/stream.c | 2 ++
  1 file changed, 2 insertions(+)

Stefan Weil already posted a similar patch:
http://patchwork.ozlabs.org/patch/276936/

Re: [Qemu-devel] [PATCH 3/3] block/stream.c: ensure copy always set

2013-09-24 Thread Alex Bennée 

stefa...@redhat.com writes:

 On Mon, Sep 23, 2013 at 05:07:30PM +0100, alex.ben...@linaro.org wrote:
 From: Alex Bennée a...@bennee.com
 
 This only showed up when compiling with
 --enable-trace-backend=stderr|ftrace at which point the compiler
 complains with the following:
nsip

 Stefan Weil already posted a similar patch:
 http://patchwork.ozlabs.org/patch/276936/

OK I'll drop the patch in v3 which I guess is getting ready to be a
proper PULL request ;-)

What's the typical lag for trivial patches getting in? I see there are
periodic trivial pull requests. I assume there are maintainers that
collect these up into trees?

-- 
Alex Bennée

[Qemu-devel] [PATCH 3/3] block/stream.c: ensure copy always set

2013-09-23 Thread alex . bennee 
From: Alex Bennée a...@bennee.com

This only showed up when compiling with
--enable-trace-backend=stderr|ftrace at which point the compiler
complains with the following:

block/stream.c: In function ‘stream_run’:
block/stream.c:141:22: error: ‘copy’ may be used uninitialized in this function 
[-Werror=uninitialized]

Not sure exactly why it needs these options but it does seem clear the
negative return case should be handled.
---
 block/stream.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/block/stream.c b/block/stream.c
index 078ce4a..3b9c198 100644
--- a/block/stream.c
+++ b/block/stream.c
@@ -136,6 +136,8 @@ wait:
 }
 
 copy = (ret == 1);
+} else {
+copy = false;
 }
 trace_stream_one_iteration(s, sector_num, n, ret);
 if (ret = 0  copy) {
-- 
1.8.4