From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39362 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PAJrS-00012T-TA for qemu-devel@nongnu.org; Mon, 25 Oct 2010 06:01:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PAJrQ-0001dV-E8 for qemu-devel@nongnu.org; Mon, 25 Oct 2010 06:01:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20260) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PAJrQ-0001dD-4k for qemu-devel@nongnu.org; Mon, 25 Oct 2010 06:01:00 -0400 Message-ID: <4CC55554.4060103@redhat.com> Date: Mon, 25 Oct 2010 12:00:52 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 1/2] Type-safe ioport callbacks References: <1287934469-16624-1-git-send-email-avi@redhat.com> <1287934469-16624-2-git-send-email-avi@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 10/24/2010 08:14 PM, Blue Swirl wrote: > On Sun, Oct 24, 2010 at 3:34 PM, Avi Kivity wrote: > > The current ioport callbacks are not type-safe, in that they accept an "opaque" > > pointer as an argument whose type must match the argument to the registration > > function; this is not checked by the compiler. > > > > This patch adds an alternative that is type-safe. Instead of an opaque > > argument, both registation and the callback use a new IOPort type. The > > callback then uses container_of() to access its main structures. > > > > Currently the old and new methods exist side by side; once the old way is gone, > > we can also save a bunch of memory since the new method requires one pointer > > per ioport instead of 6. > > > > Signed-off-by: Avi Kivity > > If we are going to change the interface, let's do it so that it's > useful for other uses too: > http://article.gmane.org/gmane.comp.emulators.qemu/76984 I don't really see why we need registration; cpu_register_io() takes function pointers, a size, and an opaque, and gives an integer handle in return. With the IOPort object approach, you set up the IOPort with function pointers, size is implied, and the opaque is derived using container_of(); the handle is simply the address of the object. > > +typedef struct IOPort { > > + IOPortOps *ops; > > const Yup, will fix. Will repost once we agree on the approach. -- error compiling committee.c: too many arguments to function