From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH v2 07/13] xsplice: Add helper elf routines
	(v2)
Date: Fri, 5 Feb 2016 13:38:00 -0500
Message-ID: <20160205183800.GC26294@x230.dumpdata.com>
References: <1452808031-706-1-git-send-email-konrad.wilk@oracle.com>
	<1452808031-706-8-git-send-email-konrad.wilk@oracle.com>
	<569E491D.2070207@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1aRlGm-0005h8-Bj
	for xen-devel@lists.xenproject.org; Fri, 05 Feb 2016 18:38:12 +0000
Content-Disposition: inline
In-Reply-To: <569E491D.2070207@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ross Lagerwall <ross.lagerwall@citrix.com>
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com, mpohlack@amazon.com, stefano.stabellini@citrix.com, jbeulich@suse.com, sasha.levin@oracle.com, xen-devel@lists.xenproject.org
List-Id: xen-devel@lists.xenproject.org

> >+#define return_(x) { printk(XENLOG_DEBUG "%s:%d rc: %d\n",  \
> >+                            __func__,__LINE__, x); return x; }
> >+

.. snip..
> >+        printk(XENLOG_ERR "Could not allocate memory for section table!\n");
> 
> Shouldn't this printk be removed if you're using return_?

I was torn on the return_ macro. At one hand it helps to identify what
went wrong with the payload file. But at the same time it is very
developer-centric - so perhaps not to be in the final piece.

And yes, if we do want to go ahead with the return_ macro, then this
should go away.