From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45581) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rxz7M-0005PA-5Y for qemu-devel@nongnu.org; Thu, 16 Feb 2012 06:03:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rxz7I-0003Cx-5n for qemu-devel@nongnu.org; Thu, 16 Feb 2012 06:03:16 -0500 Received: from mx1.redhat.com ([209.132.183.28]:11827) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rxz7H-0003Cq-Tg for qemu-devel@nongnu.org; Thu, 16 Feb 2012 06:03:12 -0500 Message-ID: <4F3CE33E.4020600@redhat.com> Date: Thu, 16 Feb 2012 12:06:38 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <20120215184515.GA32249@redhat.com> <4F3BFFB3.5000806@siemens.com> In-Reply-To: <4F3BFFB3.5000806@siemens.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] slirp: kill ugly macros List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: "qemu-devel@nongnu.org" , "Michael S. Tsirkin" Am 15.02.2012 19:55, schrieb Jan Kiszka: > On 2012-02-15 19:45, Michael S. Tsirkin wrote: >> Remove ugly macros for field names, >> change done by the following script: >> >> s#\bifq_prev\b#m_prev#g; >> s#\bifq_next\b#m_next#g; >> s#\bifs_prev\b#m_prevpkt#g; >> s#\bifs_next\b#m_nextpkt#g; >> s#\bifq_so\b#m_so#g; >> s#\bm_next\b#m_hdr.mh_next#g; >> s#\bm_prev\b#m_hdr.mh_prev#g; >> s#\bm_nextpkt\b#m_hdr.mh_nextpkt#g; >> s#\bm_prevpkt\b#m_hdr.mh_prevpkt#g; >> s#\bm_flags\b#m_hdr.mh_flags#g; >> s#\bm_len\b#m_hdr.mh_len#g; >> s#\bm_data\b#m_hdr.mh_data#g; >> s#\bm_size\b#m_hdr.mh_size#g; >> s#\bm_dat\b#M_dat.m_dat_#g; >> s#\bm_ext\b#M_dat.m_ext_#g; > > Could you convert M_dat to m_dat as well (do not script, it's also a > type)? It looks strange. What are all these m_ and mh_ prefixes for struct fields even about? When I have an mbuf, I know perfectly well that it is one, and that m_hdr is a header of it. So while we're cleaning up here, wouldn't mbuf->hdr->next make more sense than mbuf->m_hdr->mh_next? Kevin