From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50440) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUw7l-0004BS-JV for qemu-devel@nongnu.org; Thu, 27 Aug 2015 08:17:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUw7i-0006Ug-EI for qemu-devel@nongnu.org; Thu, 27 Aug 2015 08:17:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37620) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUw7i-0006Tl-9O for qemu-devel@nongnu.org; Thu, 27 Aug 2015 08:17:42 -0400 Date: Thu, 27 Aug 2015 15:17:37 +0300 From: "Michael S. Tsirkin" Message-ID: <20150827151601-mutt-send-email-mst@redhat.com> References: <1440583448-15797-1-git-send-email-jasowang@redhat.com> <20150826165140.6bab7d28@bahia.local> <55DE970B.6040807@redhat.com> <20150827135126-mutt-send-email-mst@redhat.com> <20150827140715-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 1/2] memory: allow zero size for adjust_endianness() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Paolo Bonzini , Jason Wang , QEMU Developers , Greg Kurz On Thu, Aug 27, 2015 at 01:12:32PM +0100, Peter Maydell wrote: > On 27 August 2015 at 12:08, Michael S. Tsirkin wrote: > > On Thu, Aug 27, 2015 at 12:04:49PM +0100, Peter Maydell wrote: > >> On 27 August 2015 at 11:53, Michael S. Tsirkin 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