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 6E897A0540; Mon, 20 Jul 2020 14:32:34 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4068D1DBB; Mon, 20 Jul 2020 14:32:33 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 41517A69 for ; Mon, 20 Jul 2020 14:32:30 +0200 (CEST) IronPort-SDR: c4zrEItjJkhR4NyYxIQDlIOEON63F3rphhTrhdOeTDN5sPA490uuq+miMvGiBI5ulkgOsP5fF4 95S9yOmY0E0Q== X-IronPort-AV: E=McAfee;i="6000,8403,9687"; a="151240320" X-IronPort-AV: E=Sophos;i="5.75,375,1589266800"; d="scan'208";a="151240320" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jul 2020 05:32:28 -0700 IronPort-SDR: UjJWji7TqLjjaAnhQpnOLe05zFamgxnVxLAm8ZUpOiafoG2k44GuhiFwZR/xu8RLUPcK2Wj4FN F1a0S1zoU0eA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,375,1589266800"; d="scan'208";a="319511514" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.194.218]) ([10.213.194.218]) by fmsmga002.fm.intel.com with ESMTP; 20 Jul 2020 05:32:28 -0700 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> From: "Burakov, Anatoly" Message-ID: Date: Mon, 20 Jul 2020 13:32:27 +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: <20200717192235.3636fcce@hermes.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 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 :) -- Thanks, Anatoly