On 3/10/21 1:32 PM, Fam Zheng wrote:
> On Wed, 10 Mar 2021 at 11:44, Philippe Mathieu-Daudé <philmd@redhat.com
> <mailto:philmd@redhat.com>> 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
> <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.
>
> The 2nd patch is RFC because I won't spend time converting the
> tests until the first patch is discussed, as I already spent enough
> time doing that in the previous mentioned series.
>
> Regards,
>
> Phil.
>
> Philippe Mathieu-Daudé (3):
> block: Introduce the 'zeroes-co' driver
> tests/test-blockjob: Use zeroes-co instead of null-co,read-zeroes=on
> docs/secure-coding-practices: Describe null-co/zeroes-co block drivers
>
> docs/devel/secure-coding-practices.rst | 7 +
> block/zeroes.c | 306 +++++++++++++++++++++++++
>
> Why not add another BlockDriver struct to block/null.c and set the
> read_zeroes field in the .bdrv_file_open callback? It would make the
> patch much simpler.
This is the first patch I wrote but then realized you are listed as
null-co maintainer, so you might be uninterested in having this new
driver in the same file. And declaring the prototypes public to
reuse them seemed overkill.
I posted a patch for block/null.c to add the same interface, just as an alternative to the first patch.
I think we all agree that both zeroed and non-zeroed read mode will be supported going forward, the divergence is on approach:
a) -blockdev null-co:// | -blockdev null-co://,read-zeroes=off,
if we make read-zeroes=on the default.
b) -blockdev null-co:// | -blockdev zero-co://,
if we keep the current default of null-co://, but introduce zero-co:// which has a clearer interface.
Fam