From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55892) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RxbJO-0008Io-6s for qemu-devel@nongnu.org; Wed, 15 Feb 2012 04:38:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RxbJH-0008VJ-4B for qemu-devel@nongnu.org; Wed, 15 Feb 2012 04:38:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:19481) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RxbJG-0008Up-Tj for qemu-devel@nongnu.org; Wed, 15 Feb 2012 04:37:59 -0500 Date: Wed, 15 Feb 2012 11:38:00 +0200 From: "Michael S. Tsirkin" Message-ID: <20120215093800.GB30825@redhat.com> References: <1329293521-16197-1-git-send-email-zwu.kernel@gmail.com> <4F3B6D1F.9010607@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F3B6D1F.9010607@web.de> Subject: Re: [Qemu-devel] [PATCH 1/2] slirp: remove duplicate definition List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: zwu.kernel@gmail.com, Zhi Yong Wu , qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com On Wed, Feb 15, 2012 at 09:30:23AM +0100, Jan Kiszka wrote: > On 2012-02-15 09:12, zwu.kernel@gmail.com wrote: > > From: Zhi Yong Wu > > > > Signed-off-by: Zhi Yong Wu > > --- > > slirp/if.c | 2 -- > > 1 files changed, 0 insertions(+), 2 deletions(-) > > > > diff --git a/slirp/if.c b/slirp/if.c > > index 2852396..8e0cac2 100644 > > --- a/slirp/if.c > > +++ b/slirp/if.c > > @@ -8,8 +8,6 @@ > > #include > > #include "qemu-timer.h" > > > > -#define ifs_init(ifm) ((ifm)->ifs_next = (ifm)->ifs_prev = (ifm)) > > - > > static void > > ifs_insque(struct mbuf *ifm, struct mbuf *ifmhead) > > { > > Let's grab the chance and move ifs_init to mbuf.h. > > Jan > Since you mention it - why does slirp have all these defines in the first place? slirp/mbuf.h:#define m_nextpkt m_hdr.mh_nextpkt slirp/mbuf.h:#define ifs_next m_nextpkt Seriously, #define for a field name? This is just crazy, and violates our coding style which requires macros to be PPER_CAS_WITH_UNDERSCORES -- MST