| Message ID | 1379952450-29640-4-git-send-email-alex.bennee@linaro.org |
|---|---|
| State | New |
| Headers | show |
On Mon, Sep 23, 2013 at 05:07:30PM +0100, alex.bennee@linaro.org wrote: > From: Alex Bennée <alex@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/
stefanha@redhat.com writes: > On Mon, Sep 23, 2013 at 05:07:30PM +0100, alex.bennee@linaro.org wrote: >> From: Alex Bennée <alex@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?
On Tue, Sep 24, 2013 at 03:27:49PM +0100, Alex Bennée wrote: > > stefanha@redhat.com writes: > > > On Mon, Sep 23, 2013 at 05:07:30PM +0100, alex.bennee@linaro.org wrote: > >> From: Alex Bennée <alex@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
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) {
From: Alex Bennée <alex@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(+)