Re: [Qemu-devel] [PATCH 1/2] memory: allow zero size for adjust_endianness()

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Aug 27, 2015 at 01:12:32PM +0100, Peter Maydell wrote:
> On 27 August 2015 at 12:08, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Thu, Aug 27, 2015 at 12:04:49PM +0100, Peter Maydell wrote:
> >> On 27 August 2015 at 11:53, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> > On Thu, Aug 27, 2015 at 11:49:32AM +0100, Peter Maydell wrote:
> >> >> But *why* does it require the size to be zero? I still think
> >> >> the caller should just avoid trying to do zero-size memory
> >> >> operations: they don't make sense. What is a zero size
> >> >> operation supposed to mean?
> >>
> >> > This just mirrors an API we have in kvm: if you pass 0
> >> > size when registering an ioeventfd, it will match on access
> >> > of any size.
> >>
> >> Hrm. It feels to me like the memory APIs ought to filter
> >> out bad access sizes at an earlier stage, rather than
> >> trying to make them work all the way through.
> 
> > Why do you mention APIs? It's all internal to memory.c, isn't it?
> 
> adjust_endianness() is internal to memory.c. The APIs
> memory.c exposes to the rest of the world are the ones
> declared in memory.h. I'm suggesting that it would be
> better to filter out rubbish like zero sizes at the
> point where the rest of the world calls the memory
> subsystem rather than ensuring that every part of the
> memory subsystem code can handle what is basically
> a completely meaningless request.
> 
> -- PMM

Basically the point is that ABI is extended to make
ioeventfd with len = 0 mean "any length".
0 is thus not meaningless anymore.

-- 
MST