[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] structured reply behavior for read of 0 bytes
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] structured reply behavior for read of 0 bytes |
Date: |
Mon, 6 Nov 2017 10:11:29 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
On 11/05/2017 01:57 PM, Wouter Verhelst wrote:
>
> I'd like to take a step back first and wonder what a zero-sized read
> would actually mean. "Please read no data at this offset". What good
> does that do? I can't see anything useful coming out of that.
If the export is some sort of memory-mapped device, where a read of 0
has a different action than a read of 1, then maybe it has use - but
that gets into the dirty details of a client and server that know what
to expect. I agree that in the generic case it's probably easiest to
just leave things as unspecified behavior results.
I know that a 0-byte write is an interesting probe - does that succeed
on a read-only export, even when a write of one byte fails? But that
just strengthens the argument that normal clients won't be doing 0-byte
transactions. It is also feasible that some client/server pair may want
to special-case a length of 0 as meaning 4G.
>
> If we can come up with some useful semantics that we could apply to a
> zero-sized read, then I guess it makes sense to worry about handling it.
> In the absense of that though, I think it is more appropriate to just
> document that a client should not send it, but that a server's behaviour
> upon such a command is not defined (other than that it should not cause
> the server to quit, through a crash or otherwise).
I'll propose wording along those lines.
>
> In fact, the current spec, as you point out, already implicitly forbids
> (with MUST) nonzero writes by requiring a data chunk to have nonzero
> payload (and that can't happen when you have a zero-sized read). It
> might make sense to make that explicit.
>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature