[Top][All Lists]

[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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]