[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] null-co undefined read behavior
From: |
Eric Blake |
Subject: |
Re: [Qemu-block] null-co undefined read behavior |
Date: |
Tue, 27 Jun 2017 12:25:44 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 |
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 removes the warning. Or we could
> make it mandatory there, too.
I'm late to the conversation, but I like this approach...
>
> These changes are incompatible, but I think the null-* use cases are
> mostly about testing and debugging, so I feel we can be a bit laxer
> about compatibility (like we already are with blkdebug).
Since null-co is a debug-only interface, I'm not as worried about
backwards-compatibility, and making the option mandatory forces clients
that are debugging to be explicit on whether they want defined reads or
fast behavior. Once the option is mandatory, then it is also feasible
to use valgrind macros to unconditionally shut up the warning about
uninitialized reads, even when we are intentionally not zeroing the
memory, because at that point the request for fast behavior is intentional.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
- Re: [Qemu-block] null-co undefined read behavior, (continued)
Re: [Qemu-block] null-co undefined read behavior, Stefan Hajnoczi, 2017/06/13