From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 423E1A0526; Wed, 22 Jul 2020 12:08:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7C9571BFD1; Wed, 22 Jul 2020 12:08:01 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id A74C41BE90 for ; Wed, 22 Jul 2020 12:07:59 +0200 (CEST) IronPort-SDR: fAArYfrWTCwc9j2GH9ex3blMeuA3qCPPYh4CyF/NUOgxhOub91oHFdJrBdOiZaCWd7Juw5TPpA HqCq4Q5VdlrA== X-IronPort-AV: E=McAfee;i="6000,8403,9689"; a="149467305" X-IronPort-AV: E=Sophos;i="5.75,381,1589266800"; d="scan'208";a="149467305" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jul 2020 03:07:57 -0700 IronPort-SDR: Ts8OcdyVay78T97+ptzHBgkHRm0kZ2koHkSWsiptY67voHBXB0HVXXRPdYQ9PqB0QEp0iIylvp ewriPnP7RnAA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,381,1589266800"; d="scan'208";a="362665991" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.249.35.227]) ([10.249.35.227]) by orsmga001.jf.intel.com with ESMTP; 22 Jul 2020 03:07:56 -0700 From: "Burakov, Anatoly" To: Stephen Hemminger Cc: dev@dpdk.org References: <20200604210200.25405-1-stephen@networkplumber.org> <20200701202359.17006-1-stephen@networkplumber.org> <20200701202359.17006-26-stephen@networkplumber.org> <20200715132910.5aaa11ed@hermes.lan> <2e34fe08-6548-e474-a7bc-f10e4bef947a@intel.com> <20200716150429.664a524e@hermes.lan> <88cf6911-c0e5-1f37-5f2d-51232d8dc787@intel.com> <20200717192235.3636fcce@hermes.lan> <20200720115112.14ef4f5d@hermes.lan> Message-ID: <65c4665e-d6ed-ee07-8ea7-71335f43a571@intel.com> Date: Wed, 22 Jul 2020 11:07:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v4 25/27] eal: mark old naming as deprecated 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 22-Jul-20 10:05 AM, Burakov, Anatoly wrote: > On 20-Jul-20 7:51 PM, Stephen Hemminger wrote: >> On Mon, 20 Jul 2020 13:32:27 +0100 >> "Burakov, Anatoly" wrote: >> >>> On 18-Jul-20 3:22 AM, Stephen Hemminger wrote: >>>> On Fri, 17 Jul 2020 16:21:37 +0100 >>>> "Burakov, Anatoly" wrote: >>>>> On 16-Jul-20 11:04 PM, Stephen Hemminger wrote: >>>>>> On Thu, 16 Jul 2020 14:41:41 +0100 >>>>>> "Burakov, Anatoly" wrote: >>>>>>> On 15-Jul-20 9:29 PM, Stephen Hemminger wrote: >>>>>>>> On Wed, 15 Jul 2020 14:28:17 +0100 >>>>>>>> "Burakov, Anatoly" wrote: >>>>>>>>>> -#define SKIP_MASTER    SKIP_INITIAL >>>>>>>>>> -#define CALL_MASTER    CALL_INITIAL >>>>>>>>>> +#define SKIP_MASTER _Pragma("GCC warning \"'SKIP_MASTER' is >>>>>>>>>> deprecated\"") SKIP_INITIAL >>>>>>>>>> +#define CALL_MASTER _Pragma("GCC warning \"'CALL_MASTER' is >>>>>>>>>> deprecated\"") CALL_INITIAL >>>>>>>>> >>>>>>>>> Presumably this is a generic header, should we introduce >>>>>>>>> GCC-specific >>>>>>>>> things there? >>>>>>>> >>>>>>>> It works with Clang as well. Likely ICC but don't have that. >>>>>>> >>>>>>> What about MSVC? >>>>>> >>>>>> _Pragma is C99 standard so MSVC know it. >>>>>> MSVC should ignore any pragman it doesn't understand. >>>>>> >>>>>> There is a better pragma for deprecating keywords in MSVC, but GCC >>>>>> and Clang don't >>>>>> understand it. >>>>> >>>>> Deprecating macros sounds like something we might want to do in the >>>>> future, can't we put some macro into rte_common.h to address this? >>>>> e.g. >>>>> something like >>>>> >>>>> #ifdef MSVC >>>>> #define rte_deprecated_macro _msvc_pragma_whatever() >>>>> #else >>>>> #define rte_deprecated_macro _Pragma("GCC warning ...") >>>>> #endif >>>>> >>>>> and use this macro here? >>>> >>>> It gets hard to do macro in a macro, >>> >>> I don't have a strong opinion on this, but IMO it's certainly better >>> than having a compiler-specific things in an API header file :) >>> >> >> I was hoping for macro volunteer? >> >> Something like: >> #define RTE_DEPRECATED(foo) ... >> > > Oh, sure, apologies for not picking up on that :D > > A bit on the ugly side, but should work: > > #define __rte_deprecated_macro(val) (_Pragma("GCC warning \"'" #val "'\" > is deprecated\"") (val)) > > To be used as: > > #define NEW __rte_deprecated_macro(OLD) > > (I feel there could be confusion between __rte_deprecated and > RTE_DEPRECATED, so both for consistency and clarity, i believe > "__rte_deprecated_macro" would be a better name - however, no strong > opinion, RTE_DEPRECATED is fine by me as well) > Sorry, realized that i've done it the other way around :D Perhaps this one would be better: #define __rte_deprecated_macro(old) _Pragma("GCC warning \"'" #old "'\" is deprecated\"") ... #define OLD __rte_deprecated_macro(OLD) NEW -- Thanks, Anatoly