From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 342E8A00C3; Mon, 17 Jan 2022 19:37:52 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 17201426D2; Mon, 17 Jan 2022 19:37:52 +0100 (CET) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by mails.dpdk.org (Postfix) with ESMTP id 77ACF40140 for ; Mon, 17 Jan 2022 19:37:50 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id BF93E580433; Mon, 17 Jan 2022 13:37:49 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 17 Jan 2022 13:37:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= EixyWk7jforUoHiw0c7cPYlcfI4dnbqH4rKsiW0SCDM=; b=nZJUvlLqMo5+cKyq Jd9MA2RXCGVGGgLuf+uX1hKHcxihBf7owjoPEUOeOJurrIVhMd43xUa1OJgoF1ZG mE1IEKmDU9Ww5K3noBpoF9+C3HlABFCGpv9md8PVvvjRdR3uxsQUX/1pL6yMGMJ4 CAYXW+Hu0Muu4XuT/Mg/jnQk2jVBFkeSVLpclciMMuvg4OHvsHA9IZvMueKbubaK 3H7o5cBq4ju66CWc2L5LFLDnq2ZJOR5B1ss/A7jaFy6C1uPnTQc1hsCjVPsTpOl/ uyBHVaWyDqlzNmRwWjED3gQFdWk5SS1I+sJ+tUwwBiHBZXwl2EmL1nf+flLgTV6k qJrs/w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=EixyWk7jforUoHiw0c7cPYlcfI4dnbqH4rKsiW0SC DM=; b=J/81yi7+ixmvVEAi3CrE1s1rOzh4nKdWRUXD586fpq/gpWEiRLkPcCGJn +iBMjS3EmDHXBERDzQn3kGCXknbRDnTq/pptU8yZqn1brCMbikP1J0vJmF4NzXrR l62G15KNKQ1aLO50ETRlhmzbTvos7G36oVxtSZrTMmo+sdxz7WWXnv0i0WzDfphf rVd80vSjBtne+N1/NOSgf+EC6Fb7ArgURieg6WeWbjFDiJDjqqcMJPbFQHzvSSjT znkjnPYsWDRodemyy52tskw/Qr5XisFSPIW4lbLOAakoTSxXzQV8D6X58FYi8396 w+9/gq5Wpj/wTHQr+3ykeoP7xkSYQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddruddugdduudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 17 Jan 2022 13:37:48 -0500 (EST) From: Thomas Monjalon To: Jie Zhou Cc: Dmitry Kozlyuk , dev@dpdk.org, Aaron Conole , Jerin Jacob , dpdk-dev , roretzla@microsoft.com, Narcisa Ana Maria Vasile , "Dmitry Malloy (MESHCHANINOV)" , Pallavi Kadam , talshn@nvidia.com, Bruce Richardson Subject: Re: [PATCH v14 04/11] app/test: skip interrupt tests on Windows Date: Mon, 17 Jan 2022 19:37:46 +0100 Message-ID: <9126706.2WqB4rESCP@thomas> In-Reply-To: References: <1638928262-13177-1-git-send-email-jizh@linux.microsoft.com> <20211210122359.17a1be53@sovereign> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org The proposal below is now merged. Please Jie, use it in a v15 of this series. 10/12/2021 10:30, Bruce Richardson: > On Fri, Dec 10, 2021 at 12:23:59PM +0300, Dmitry Kozlyuk wrote: > > 2021-12-09 16:39 (UTC+0000), Bruce Richardson: > > > On Thu, Dec 09, 2021 at 04:17:08PM +0000, Bruce Richardson wrote: > > > [...] > > > > I'm wondering if a reasonable compromise solution might be to have the > > > > build system expose a usable RTE_EXEC_ENV symbol that can be used in C-code > > > > if statements rather than just in ifdefs. That would allow us to easily add > > > > e.g. > > > > > > > > if (RTE_EXEC_ENV == rte_env_linux) > > > > return TEST_SKIPPED; > > > > > > > > into each test function needing it. Two lines of C-code is a lot easier to > > > > add and manage than #ifdefs covering the whole file, or alternative lists > > > > in meson. > > > > > > > Quick patch to allow C-code comparisons: > > > > > > diff --git a/lib/eal/meson.build b/lib/eal/meson.build > > > index 1722924f67..b5b9fa14b4 100644 > > > --- a/lib/eal/meson.build > > > +++ b/lib/eal/meson.build > > > @@ -10,6 +10,12 @@ if not is_windows > > > subdir('unix') > > > endif > > > > > > +exec_envs = {'freebsd': 0, 'linux': 1, 'windows': 2} > > > +foreach env, id:exec_envs > > > + dpdk_conf.set('RTE_ENV_' + env.to_upper(), id) > > > +endforeach > > > +dpdk_conf.set('RTE_EXEC_ENV', exec_envs[exec_env]) > > > + > > > dpdk_conf.set('RTE_EXEC_ENV_' + exec_env.to_upper(), 1) > > > subdir(exec_env) > > > > > > A slightly simpler patch would just expose the environment as a string as > > > e.g. "linux", but I think numeric ids just make the code better rather than > > > having string comparisons. Alternatively, this could also be done via > > > C-code with ifdefs in EAL, but as it stands this meson change allows: > > > > > > if (RTE_EXEC_ENV == RTE_ENV_WINDOWS) > > > ... > > > > > > or: > > > > > > switch (RTE_EXEC_ENV) { > > > case RTE_ENV_LINUX: ... ; break; > > > case RTE_ENV_FREEBSD: ... ; break; > > > case RTE_ENV_WINDOWS: ... ; break; > > > } > > > > > > Thoughts? > > > > I like this. > > Even outside of tests more code can be made to compile on all platforms > > (e.g. ixgbe_wait_for_link_up). > > Alternative naming: RTE_EXEC_ENV_IS_* (similar to RTE_CC_IS_*), > > which does not allow switch statements, but shortens most practical cases. > > Sure. I wonder if it is worthwhile implementing both, since it's not a > large amount of code. > > > Will Coverity understand that if a condition is always false, > > variables beneath still may be used on another platform? > > That I don't know, unfortunately. Perhaps some coverity experts can weigh > in.