From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id C7CA82BD3 for ; Wed, 9 Mar 2016 22:22:36 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP; 09 Mar 2016 13:22:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,312,1455004800"; d="scan'208";a="906362286" Received: from ugavish-mobl1.ger.corp.intel.com ([10.252.20.226]) by orsmga001.jf.intel.com with SMTP; 09 Mar 2016 13:22:34 -0800 Received: by (sSMTP sendmail emulation); Wed, 09 Mar 2016 21:22:32 +0025 Date: Wed, 9 Mar 2016 21:22:32 +0000 From: Bruce Richardson To: Olivier MATZ Message-ID: <20160309212232.GB8020@bricha3-MOBL3> References: <1457540381-20274-1-git-send-email-olivier.matz@6wind.com> <1457540381-20274-11-git-send-email-olivier.matz@6wind.com> <56E08BE7.6030906@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56E08BE7.6030906@6wind.com> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [RFC 10/35] eal: introduce RTE_DECONST macro X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 21:22:37 -0000 On Wed, Mar 09, 2016 at 09:47:35PM +0100, Olivier MATZ wrote: > Hi, > > On 03/09/2016 07:53 PM, Stephen Hemminger wrote: > > Can't we just write correct code rather than trying to trick the compiler. > > Thank you for your comment. This macro is introduced for next > commit, I would be happy if you could help me to remove it. > > My opinion is that using a macro like this is cleaner than doing a > discreet cast that nobody, because it is explicit. The const qualifier > is not only for the compiler, but also for people reading the code. > > In this case, the objective is to be able to do the following: > > uint32_t rte_mempool_obj_iter(struct rte_mempool *mp, > rte_mempool_obj_cb_t *obj_cb, void *obj_cb_arg) > { > /* call a function on all objects of a mempool */ > } > > static void > mempool_obj_audit(struct rte_mempool *mp, > __rte_unused void *opaque, void *obj, __rte_unused unsigned idx) > { > /* do some check on one mempool object */ > } > > > void rte_mempool_audit(const struct rte_mempool *mp) > { > /* iterate objects in mempool using rte_mempool_obj_iter() */ > } > > > In the public API: > > - rte_mempool_obj_iter() has the proper prototype: this function > can be used to make rw access to the mempool > - rte_mempool_audit() has the proper public prototype: this function > won't modify the mempool > > Internally: > - we use a deconst to be able to make use of rte_mempool_obj_iter(), > but we call a static function that won't modify the mempool. > > Note that this kind of macro is also used in projects like FreeBSD: > http://fxr.watson.org/fxr/ident?i=__DECONST > > You can also find many examples in Linux kernel where const qualifier > is silently dropped. For instance, you can grep the following in Linux: > "git grep 'iov_base = (void \*)'" > > If you have a better alternative, without duplicating the code, > I'll be happy to learn. > I really don't like this dropping of const either, but I do see the problem. I'd nearly rather see two copies of the function than start dropping the const in such a way. Also, I'd see having the function itself be a wrapper around a macro as a better alternative too, assuming such a construction is possible. /Bruce