From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 558402C27 for ; Thu, 13 Apr 2017 11:09:33 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Apr 2017 02:09:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,194,1488873600"; d="scan'208";a="955639278" Received: from irsmsx110.ger.corp.intel.com ([163.33.3.25]) by orsmga003.jf.intel.com with ESMTP; 13 Apr 2017 02:09:25 -0700 Received: from irsmsx155.ger.corp.intel.com (163.33.192.3) by irsmsx110.ger.corp.intel.com (163.33.3.25) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 13 Apr 2017 10:09:24 +0100 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.239]) by irsmsx155.ger.corp.intel.com ([169.254.14.202]) with mapi id 14.03.0319.002; Thu, 13 Apr 2017 10:09:24 +0100 From: "De Lara Guarch, Pablo" To: "De Lara Guarch, Pablo" , Olivier MATZ CC: "thomas.monjalon@6wind.com" , "dev@dpdk.org" Thread-Topic: [PATCH v2] eal: redefine logtype values Thread-Index: AQHSs6J0Kn/eiaxB5UqvpGeKIGp5bqHCDJSAgADrqcCAAAbl8A== Date: Thu, 13 Apr 2017 09:09:23 +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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiODAzNDZkMDItYzAwZC00NjY0LTgzOGQtZTFhNWQ5OGI5YmYwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Im9zWEh2cUxpaithTHY4NlFFeTVQOFpDYU1ON3NnVmxWMHlZRVZya0hxams9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2] eal: redefine logtype values X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 09:09:35 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of De Lara Guarch, > Pablo > Sent: Thursday, April 13, 2017 9:32 AM > To: Olivier MATZ > Cc: thomas.monjalon@6wind.com; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2] eal: redefine logtype values >=20 > Hi Olivier, >=20 > > -----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 > > > > Hi Pablo, > > > > > > 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: > > > > /* 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; > > } > > > > if (enable) > > rte_log_set_level(type, 0); > > else > > rte_log_set_level(type, RTE_LOG_DEBUG); > > } > > > > /* Get global log type */ > > __rte_deprecated uint32_t > > rte_get_log_type(void) > > { > > return rte_logs.type; > > } > > > > > > There is a problem in these functions because they expect bitmasks > > for the first part. > > > > I does not look so easy to both fix the issue and keep a full compat > > with previous functions. > > > > 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 mask= s > > the result with a RTE_LOGTYPE_* (which will not be a bitmask). I think > > it's a rare case. > > > > 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. > > > > Any opinion? > > I would prefer the first solution. If you want I can send a patch > > updated based on yours. >=20 > Oh yes, I missed that too. First option looks ok to me, so send a patch i= f you > like. Hi Olivier, I just saw a comment from Stephen Hemminger, so do not send the patch yet, = as I am making changes to the v2. Actually, I can make this change too, since it is a minor one. Thanks, Pablo