On Thu, Aug 27, 2015 at 01:12:32PM +0100, Peter Maydell wrote: > On 27 August 2015 at 12:08, Michael S. Tsirkin <m...@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 <m...@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
