From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <olivier.matz@6wind.com>
Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67])
 by dpdk.org (Postfix) with ESMTP id 6C8B92BAD
 for <dev@dpdk.org>; Wed,  9 Mar 2016 21:47:42 +0100 (CET)
Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214]
 helo=[192.168.0.10])
 by mail.droids-corp.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84) (envelope-from <olivier.matz@6wind.com>)
 id 1adl2f-0006G0-PF; Wed, 09 Mar 2016 21:49:15 +0100
To: Stephen Hemminger <stephen@networkplumber.org>
References: <1457540381-20274-1-git-send-email-olivier.matz@6wind.com>
 <1457540381-20274-11-git-send-email-olivier.matz@6wind.com>
 <CAOaVG17eXh8B7kPvtWsH6q6q1E0S0kgT+fhAz_6C3k0=5iM40g@mail.gmail.com>
From: Olivier MATZ <olivier.matz@6wind.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <56E08BE7.6030906@6wind.com>
Date: Wed, 9 Mar 2016 21:47:35 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Icedove/38.6.0
MIME-Version: 1.0
In-Reply-To: <CAOaVG17eXh8B7kPvtWsH6q6q1E0S0kgT+fhAz_6C3k0=5iM40g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Cc: "dev@dpdk.org" <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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Mar 2016 20:47:42 -0000

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.


Thanks,
Olivier