Re: [Qemu-block] null-co undefined read behavior

2017-06-27 Thread Eric Blake
On 06/13/2017 05:55 AM, Kevin Wolf wrote: > > We could possibly make read-zeroes a mandatory option in QAPI > (currently it seems it doesn't even exist - oops!) and if we really want > to print warnings for -drive, do it only if the default is used so that > passing an explicit read-zeroes=off

Re: [Qemu-block] null-co undefined read behavior

2017-06-16 Thread Stefan Hajnoczi
On Wed, Jun 14, 2017 at 07:54:17PM +0200, Kevin Wolf wrote: > Am 14.06.2017 um 19:44 hat John Snow geschrieben: > > On 06/13/2017 03:52 AM, Kevin Wolf wrote: > > > Am 12.06.2017 um 23:20 hat John Snow geschrieben: > > >> (5) Shut up, John, really, who cares? Please shut up. You are the only > > >>

Re: [Qemu-block] null-co undefined read behavior

2017-06-14 Thread Kevin Wolf
Am 14.06.2017 um 19:44 hat John Snow geschrieben: > > > On 06/13/2017 03:52 AM, Kevin Wolf wrote: > > Am 12.06.2017 um 23:20 hat John Snow geschrieben: > >> I noticed while debugging an unrelated test that our use of the null > >> driver has a habit of making functions like find_image_format

Re: [Qemu-block] null-co undefined read behavior

2017-06-14 Thread John Snow
On 06/13/2017 03:52 AM, Kevin Wolf wrote: > Am 12.06.2017 um 23:20 hat John Snow geschrieben: >> I noticed while debugging an unrelated test that our use of the null >> driver has a habit of making functions like find_image_format trigger a >> lot of uninitialized memory errors in valgrind,

Re: [Qemu-block] null-co undefined read behavior

2017-06-13 Thread Max Reitz
On 2017-06-13 12:42, Stefan Hajnoczi wrote: > On Mon, Jun 12, 2017 at 05:20:55PM -0400, John Snow wrote: >> (3) Edit any tests to always use the zero option when using the null >> driver, and then periodically keep updating this option in a losing >> battle over time. > > read-zeroes=on would

Re: [Qemu-block] null-co undefined read behavior

2017-06-13 Thread Max Reitz
On 2017-06-13 10:43, Fam Zheng wrote: > On Tue, 06/13 09:52, Kevin Wolf wrote: >> (6) Make read-zeroes=on the default. Gives people worse performance if >> they expect that null-co:// without any options is the fastest thing >> possible, but it has defined behaviour by default which seems good. >

Re: [Qemu-block] null-co undefined read behavior

2017-06-13 Thread Stefan Hajnoczi
On Mon, Jun 12, 2017 at 05:20:55PM -0400, John Snow wrote: > (3) Edit any tests to always use the zero option when using the null > driver, and then periodically keep updating this option in a losing > battle over time. read-zeroes=on would have been a nicer default value because changing it

Re: [Qemu-block] null-co undefined read behavior

2017-06-13 Thread Fam Zheng
On Tue, 06/13 10:47, Kevin Wolf wrote: > Am 13.06.2017 um 10:43 hat Fam Zheng geschrieben: > > On Tue, 06/13 09:52, Kevin Wolf wrote: > > > (6) Make read-zeroes=on the default. Gives people worse performance if > > > they expect that null-co:// without any options is the fastest thing > > >

Re: [Qemu-block] null-co undefined read behavior

2017-06-13 Thread Kevin Wolf
Am 13.06.2017 um 10:43 hat Fam Zheng geschrieben: > On Tue, 06/13 09:52, Kevin Wolf wrote: > > (6) Make read-zeroes=on the default. Gives people worse performance if > > they expect that null-co:// without any options is the fastest thing > > possible, but it has defined behaviour by default which

Re: [Qemu-block] null-co undefined read behavior

2017-06-13 Thread Fam Zheng
On Tue, 06/13 09:52, Kevin Wolf wrote: > (6) Make read-zeroes=on the default. Gives people worse performance if > they expect that null-co:// without any options is the fastest thing > possible, but it has defined behaviour by default which seems good. Not that it really matters, but null-co://

Re: [Qemu-block] null-co undefined read behavior

2017-06-13 Thread Kevin Wolf
Am 12.06.2017 um 23:20 hat John Snow geschrieben: > I noticed while debugging an unrelated test that our use of the null > driver has a habit of making functions like find_image_format trigger a > lot of uninitialized memory errors in valgrind, because it will return a > successful read without

Re: [Qemu-block] null-co undefined read behavior

2017-06-12 Thread Fam Zheng
On Mon, 06/12 17:20, John Snow wrote: > I noticed while debugging an unrelated test that our use of the null > driver has a habit of making functions like find_image_format trigger a > lot of uninitialized memory errors in valgrind, because it will return a > successful read without actually

[Qemu-block] null-co undefined read behavior

2017-06-12 Thread John Snow
I noticed while debugging an unrelated test that our use of the null driver has a habit of making functions like find_image_format trigger a lot of uninitialized memory errors in valgrind, because it will return a successful read without actually touching the buffer. I see that in March there was