From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:47517)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <afaerber@suse.de>) id 1Rxnrg-0004I4-Mw
	for qemu-devel@nongnu.org; Wed, 15 Feb 2012 18:02:21 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <afaerber@suse.de>) id 1Rxnrf-0006Qf-BC
	for qemu-devel@nongnu.org; Wed, 15 Feb 2012 18:02:20 -0500
Received: from cantor2.suse.de ([195.135.220.15]:40704 helo=mx2.suse.de)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <afaerber@suse.de>) id 1Rxnre-0006Qa-UO
	for qemu-devel@nongnu.org; Wed, 15 Feb 2012 18:02:19 -0500
Message-ID: <4F3C3977.1060306@suse.de>
Date: Thu, 16 Feb 2012 00:02:15 +0100
From: =?ISO-8859-1?Q?Andreas_F=E4rber?= <afaerber@suse.de>
MIME-Version: 1.0
References: <1329293521-16197-1-git-send-email-zwu.kernel@gmail.com>
	<4F3B6D1F.9010607@web.de> <20120215093800.GB30825@redhat.com>
In-Reply-To: <20120215093800.GB30825@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH 1/2] slirp: remove duplicate definition
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: zwu.kernel@gmail.com, Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>, Jan Kiszka <jan.kiszka@web.de>, qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com

Am 15.02.2012 10:38, schrieb Michael S. Tsirkin:
> why does slirp have all these
> defines in the first place?
>=20
> slirp/mbuf.h:#define m_nextpkt  m_hdr.mh_nextpkt
> slirp/mbuf.h:#define ifs_next m_nextpkt
>=20
> Seriously, #define for a field name?

We have some such #defines in ibm8514 graphics card code, too (not yet
upstream). It is handy to make code match the datasheet while hiding
some of the implementation details, like two levels of array accesses
into implementation-defined-or-whatever registers.

Doesn't seem to apply here obviously. Maybe historically
m_hdr.mh_nextpkt was m_nextpkt and someone tried to avoid a full
refactoring.

Andreas

--=20
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe=
rg