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] Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
