From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RG8vH-0001sB-Px for qemu-devel@nongnu.org; Tue, 18 Oct 2011 08:37:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RG8vG-0005PS-EL for qemu-devel@nongnu.org; Tue, 18 Oct 2011 08:37:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53908) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RG8vF-0005PF-Vq for qemu-devel@nongnu.org; Tue, 18 Oct 2011 08:37:34 -0400 Date: Tue, 18 Oct 2011 14:38:39 +0200 From: "Michael S. Tsirkin" Message-ID: <20111018123839.GM28776@redhat.com> References: <20111017134349.GD6406@redhat.com> <4E9C7EE3.9050603@web.de> <20111018120549.GH28776@redhat.com> <4E9D6FC1.9040504@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E9D6FC1.9040504@siemens.com> Subject: Re: [Qemu-devel] [RFC][PATCH 11/45] msi: Factor out delivery hook List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Alex Williamson , Marcelo Tosatti , Avi Kivity , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" On Tue, Oct 18, 2011 at 02:23:29PM +0200, Jan Kiszka wrote: > On 2011-10-18 14:05, Michael S. Tsirkin wrote: > > On Mon, Oct 17, 2011 at 09:15:47PM +0200, Jan Kiszka wrote: > >> On 2011-10-17 15:43, Michael S. Tsirkin wrote: > >>> On Mon, Oct 17, 2011 at 11:27:45AM +0200, Jan Kiszka wrote: > >>>> diff --git a/hw/msi.c b/hw/msi.c > >>>> index 3c7ebc3..9055155 100644 > >>>> --- a/hw/msi.c > >>>> +++ b/hw/msi.c > >>>> @@ -40,6 +40,14 @@ > >>>> /* Flag for interrupt controller to declare MSI/MSI-X support */ > >>>> bool msi_supported; > >>>> > >>>> +static void msi_unsupported(MSIMessage *msg) > >>>> +{ > >>>> + /* If we get here, the board failed to register a delivery handler. */ > >>>> + abort(); > >>>> +} > >>>> + > >>>> +void (*msi_deliver)(MSIMessage *msg) = msi_unsupported; > >>>> + > >>> > >>> How about we set this to NULL, and check it instead of the bool > >>> flag? > >>> > >> > >> Yeah. I will introduce > >> > >> bool msi_supported(void) > >> { > >> return msi_deliver != msi_unsupported; > >> } > >> > >> OK? > >> > >> Jan > >> > > > > Looks a bit weird ... > > NULL is a pretty standard value for an invalid pointer, isn't it? > > Save us the runtime check and is equally expressive and readable IMHO. > > Jan Do we need to check? NULL dereference leads to a crash just as surely... > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux