From mboxrd@z Thu Jan 1 00:00:00 1970 From: "De Lara Guarch, Pablo" Subject: Re: [PATCH v2] eal: redefine logtype values Date: Thu, 13 Apr 2017 08:32:19 +0000 Message-ID: References: <1492006471-114636-1-git-send-email-pablo.de.lara.guarch@intel.com> <1492011332-5846-1-git-send-email-pablo.de.lara.guarch@intel.com> <20170412212347.0cd1966d@neon> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "thomas.monjalon@6wind.com" , "dev@dpdk.org" To: Olivier MATZ Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 14C152C27 for ; Thu, 13 Apr 2017 10:32:23 +0200 (CEST) In-Reply-To: <20170412212347.0cd1966d@neon> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Olivier, > -----Original Message----- > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > Sent: Wednesday, April 12, 2017 8:24 PM > To: De Lara Guarch, Pablo > Cc: thomas.monjalon@6wind.com; dev@dpdk.org > Subject: Re: [PATCH v2] eal: redefine logtype values >=20 > Hi Pablo, >=20 >=20 > On Wed, 12 Apr 2017 16:35:32 +0100 > Pablo de Lara wrote: ... >=20 >=20 > Thanks for spotting this issue. I think there is still a problem with > the deprecated functions for which we want to keep compat: >=20 > /* Set global log type */ > __rte_deprecated void > rte_set_log_type(uint32_t type, int enable) > { > if (type < RTE_LOGTYPE_FIRST_EXT_ID) { > if (enable) > rte_logs.type |=3D type; > else > rte_logs.type &=3D ~type; > } >=20 > if (enable) > rte_log_set_level(type, 0); > else > rte_log_set_level(type, RTE_LOG_DEBUG); > } >=20 > /* Get global log type */ > __rte_deprecated uint32_t > rte_get_log_type(void) > { > return rte_logs.type; > } >=20 >=20 > There is a problem in these functions because they expect bitmasks > for the first part. >=20 > I does not look so easy to both fix the issue and keep a full compat > with previous functions. >=20 > The first solution is your patch + add a shift in rte_set_log_type(). > It would work except if an application uses rte_get_log_type() and masks > the result with a RTE_LOGTYPE_* (which will not be a bitmask). I think > it's a rare case. >=20 > The second approach would be to define new constants for the new > functions and keep the old ones for the old functions. This approach > is probably more confusing. It also requires to check the doc and > examples again. >=20 > Any opinion? > I would prefer the first solution. If you want I can send a patch > updated based on yours. Oh yes, I missed that too. First option looks ok to me, so send a patch if = you like.