From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MbJr8-0000m7-3c
	for qemu-devel@nongnu.org; Wed, 12 Aug 2009 15:51:30 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MbJr2-0000l7-Gy
	for qemu-devel@nongnu.org; Wed, 12 Aug 2009 15:51:28 -0400
Received: from [199.232.76.173] (port=44937 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MbJr2-0000l4-Bb
	for qemu-devel@nongnu.org; Wed, 12 Aug 2009 15:51:24 -0400
Received: from mx2.redhat.com ([66.187.237.31]:43995)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1MbJr1-0006EP-Rd
	for qemu-devel@nongnu.org; Wed, 12 Aug 2009 15:51:24 -0400
Message-ID: <4A831C47.3070309@redhat.com>
Date: Wed, 12 Aug 2009 21:47:19 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] qdev: add return value to init() callbacks.
References: <1250092766-23986-1-git-send-email-kraxel@redhat.com>
	<200908122028.41012.paul@codesourcery.com>
In-Reply-To: <200908122028.41012.paul@codesourcery.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org

On 08/12/09 21:28, Paul Brook wrote:
>> We have already one case in-tree where this is needed:
>> Try -device virtio-blk-pci (without drive= specified) and watch qemu
>> segfault.
>
> No. Failure of the init routine should be fatal. i.e. virtio_blk_init_pci
> should call hw_error.

No.  That policy doesn't belong there.

> If you want to allow graceful failure  (which is pointless for commandline
> options, but may be desirable for hotplug devices)

Exactly.  And for that reason we must pass up the error to the caller. 
The caller can then decide what to do with it.  For devices added via 
command line options we probably want to exit(1).  For hotplugging we 
probably would not.

> they you need to also add
> some way of reporting why device creation failure. fprintf(stderr) is just
> plain wrong.

Indeed.  When hotplugging via monitor the error message should appear on 
the monitor, not stderr.  It is already an item on my todo list.

I'd prefer to address that in a separate patch though, the patch is 
already big and invasive enough as-is.

cheers,
   Gerd