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 4899AA0526; Wed, 22 Jul 2020 11:05:16 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 27D671BFD4; Wed, 22 Jul 2020 11:05:15 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 6A832199BC for ; Wed, 22 Jul 2020 11:05:13 +0200 (CEST) IronPort-SDR: 4Bmy4sm/nCSHvYMvlfofQyrDkbibhRwfIcDE42HuCIqhaRCuALjlGA8t/TgwIswWrXF93r+8wO yMClycBi+F2g== X-IronPort-AV: E=McAfee;i="6000,8403,9689"; a="168438266" X-IronPort-AV: E=Sophos;i="5.75,381,1589266800"; d="scan'208";a="168438266" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jul 2020 02:05:11 -0700 IronPort-SDR: sAsGwXqzuQYIPY/2BtdaJSg1vhgLzYC8xdFOBwdK3n3xa7YxaDolv9E0ItKfeFIRUbbmUCG+VD H5NvnzFaUD/g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,381,1589266800"; d="scan'208";a="362654400" 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 02:05:10 -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> <20200720115112.14ef4f5d@hermes.lan> From: "Burakov, Anatoly" Message-ID: Date: Wed, 22 Jul 2020 10:05:09 +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: <20200720115112.14ef4f5d@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 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) -- Thanks, Anatoly