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 A1B92424A1; Fri, 27 Jan 2023 13:47:41 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3EF9D40150; Fri, 27 Jan 2023 13:47:41 +0100 (CET) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id 3B9C940146 for ; Fri, 27 Jan 2023 13:47:40 +0100 (CET) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id B061E5C03C1; Fri, 27 Jan 2023 07:47:37 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 27 Jan 2023 07:47:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1674823657; x= 1674910057; bh=z8k4+RZp9AFLbnMZo4AVK0hSJlwkfM06TUmKwS9FSZc=; b=C 54LbxgZyMZX4+SzD4j/9swi2JuWyALdHySM4z6pOLFpWvdcfnapL6q/CS+VcbErO VPkZqWEDnqPlORCQw2InG4sH3au4GlIHKGuQlJQrjyeUlVorDzUQsjJOCRci9xVQ JYBmJt+FppAoYKczEvuQfyP3mak4g3AMrJ1s4rEqw0CI0CmU6ICdPlR9A/x7+Ze2 1EGUzULja3nDakcxz30apYpRRLPWVAp9hDY7v35lcW10nkoV70A1SG3P+o4rmBBX zBJWNk36/UITvlmop8leIroRd71cIOgsqVf74T7ymqb7e1q5ezghPrTqcPVlA/Nq oTxeUE52a0vIP35dMvmDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1674823657; x= 1674910057; bh=z8k4+RZp9AFLbnMZo4AVK0hSJlwkfM06TUmKwS9FSZc=; b=W eFUQ4GcwcFercIt1ZWJ3eW8Sbl0btVClC4R77IjU57pMezEeO8UAnkHECnfd5eqt iH/LVOWZHSNOFnn1+0fnMPPH4rwgp6i1AVbwq0AY2rTAvq89KioIMj9zcoMQj70I +rPZd7L7ZAoYPvU/kCuH2Y8r5V+obUqvXGr4TvCY93/pivimaDSRPrl/xrZ4n6BR YA4/CNxXmZO+p/N1OTKdbpszNvzXrd83A9oOcDTFKvaxr+rZ/jsFAlEH+QzpK1sO NC508zVifApvI0xe8ca+TlxcRs8oSnMf7DF4viRe7yRtGCLtLJlWY2N/z6pAZUjz bqxh8BZ4nlk0sHO4kPEig== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedruddviedggedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvfevufffkfgjfhgggfgtsehtuf ertddttddvnecuhfhrohhmpefvhhhomhgrshcuofhonhhjrghlohhnuceothhhohhmrghs sehmohhnjhgrlhhonhdrnhgvtheqnecuggftrfgrthhtvghrnheptdejieeifeehtdffgf dvleetueeffeehueejgfeuteeftddtieekgfekudehtdfgnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonh drnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 27 Jan 2023 07:47:36 -0500 (EST) From: Thomas Monjalon To: Tyler Retzlaff Cc: dev@dpdk.org Subject: Re: deprecation notice process / clarification Date: Fri, 27 Jan 2023 13:47:34 +0100 Message-ID: <4687038.bm5RmrZB5H@thomas> In-Reply-To: <20230125223640.GA28039@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20230125223640.GA28039@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> 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 25/01/2023 23:36, Tyler Retzlaff: > hi, > > i'm looking for some guidance when cleaning up / removing the remaining > shim functions for pthread in windows and i'm not sure how our > deprecation notice / policies apply. > > windows has been providing lib/eal/windows/include/pthread.h shim that > allowed applications to use e.g. pthread_xxx functions on windows. > > these shim functions were all being provided as inline functions and > were not part of the EAL api but on windows they were implicitly part of > the api surface exposed (to windows only). on posix platforms applications > did not rely on EAL for pthread abi or api (obviously). > > recently we introduced a set of platform agnostic thread api in the EAL. > the functions were marked __rte_experimental as a part of new API > addition policy. > > what's the most appropriate way to remove the pthread_xxx shim inline > functions from lib/eal/windows/include/pthread.h? do we have to wait the > full deprecation notice period which can't be started until we make the > new functions stable? also keeping in mind we can't actually mark inline > functions __rte_deprecated. > > is this a special case where we can just rip them out and break > compilation? Probably yes. > input is appreciated, particularly from any consumers of the windows > port who might be unhappy. I think there is not too much users of Windows DPDK yet. I would be in favor of just removing the pthread shim layer for Windows when rte_thread equivalent is declared stable.