From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45130) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScIcd-0006tK-KS for qemu-devel@nongnu.org; Wed, 06 Jun 2012 11:58:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ScIca-0003Ry-Sa for qemu-devel@nongnu.org; Wed, 06 Jun 2012 11:58:11 -0400 Message-ID: <4FCF7E08.8020706@suse.de> Date: Wed, 06 Jun 2012 17:58:00 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1338940402-28502-1-git-send-email-agraf@suse.de> <1338940402-28502-5-git-send-email-agraf@suse.de> <1338960777.15420.27.camel@PetaLogix-ws2> In-Reply-To: <1338960777.15420.27.camel@PetaLogix-ws2> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 04/31] dt: temporarily disable subtree creation failure check List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: qemu-ppc Mailing List , "qemu-devel@nongnu.org Developers" On 06/06/2012 07:32 AM, Peter Crosthwaite wrote: > On Wed, 2012-06-06 at 01:52 +0200, Alexander Graf wrote: >> Usually we want to know when creating a subtree fails. However, while >> introducing this patch set we have to modify the device tree and some >> times have the code to create a subtree in both the binary tree and >> the dynamically created tree. >> >> So ignore failures about this for now and enable them once we got rid >> of the binary device tree. >> >> Signed-off-by: Alexander Graf > Reviewed-by: Peter Crosthwaite > >> --- >> device_tree.c | 2 ++ >> 1 files changed, 2 insertions(+), 0 deletions(-) >> >> diff --git a/device_tree.c b/device_tree.c >> index 8e9262c..6cbc5af 100644 >> --- a/device_tree.c >> +++ b/device_tree.c >> @@ -203,11 +203,13 @@ int qemu_devtree_add_subnode(void *fdt, const char *name) >> } >> >> retval = fdt_add_subnode(fdt, parent, basename); >> +#if 0 >> if (retval< 0) { >> fprintf(stderr, "FDT: Failed to create subnode %s: %s\n", name, >> fdt_strerror(retval)); >> exit(1); >> } >> +#endif > Doesnt this illustrate a failure in this functions return path in the > first place?? Should this check be removed altogether and an error code > returned to the caller? That way callers (like you platform under > construction) can choose to ignore/act-on the error as appropriate. That would mean that we'd have to check every single fdt helper call for its return value. At the end of the day, we'd have an insane amount of code just for checking for potential errors, making the actual functional code unreadable. So no, the one thing that these helpers buy you vs calling libfdt manually is exactly the exit(1) :). Alex