On 3/10/21 12:55 PM, Daniel P. Berrangé wrote: > On Wed, Mar 10, 2021 at 12:43:11PM +0100, Philippe Mathieu-Daudé wrote: >> Hi, >> >> This is an alternative approach to changing null-co driver >> default 'read-zeroes' option to true: >> https://www.mail-archive.com/qemu-block@nongnu.org/msg80873.html >> >> Instead we introduce yet another block driver with an explicit >> name: 'zeroes-co'. We then clarify in secure-coding-practices.rst >> that security reports have to be sent using this new driver. > > IMHO introducing a new block driver, when this can be solved by > simply adding a property to the existing driver, just feels mad > Your previous series made much more sense, and despite the long > thread, I didn't see anyone suggest a real world blocker with > making it read zeros by default. > > I think Max's last mail sums it up pretty well > > https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg07173.html > > [quote] > In cases where we have a test that just wants a simple block node that > doesn’t use disk space, the memset() can’t be noticeable. But it’s just > a test, so do we even need the memset()? Strictly speaking, perhaps not, > but if someone is to run it via Valgrind or something, they may get > false positives, so just doing the memset() is the right thing to do. > > For performance tests, it must be possible to set read-zeroes=off, > because even though “that memset() isn’t noticeable in a functional > test”, in a hard-core performance test, it will be. > > So we need a switch. It should default to memset(), because (1) making > tools like Valgrind happy seems like a reasonable objective to me, and > (2) in the majority of cases, the memset() cannot have a noticeable > impact. > [/quote]
Yes I totally agree with Max, but Fam is the maintainer. I'll keep looking for alternatives. Maybe simply documentation. Thanks, Phil.
