From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 38698A00BE; Wed, 27 May 2020 23:27:21 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C7DCE1DAFC; Wed, 27 May 2020 23:27:19 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 6EFCF1DAF9 for <dev@dpdk.org>; Wed, 27 May 2020 23:27:18 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A1DF45C0109; Wed, 27 May 2020 17:27:17 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 27 May 2020 17:27:17 -0400 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=fm1; bh= 7o+1CzBqN+mDLnxrzBKgI5Xz8byKfGiNbl6EISG0gGk=; b=ex6hxzuoLS7QDPo9 jV8Kk+A7+K11hL7wIuxYQvu2fbon1QRyeHT1kDDEUkQzTqak+mjTp/b0U/RjhH1n thdTJWcm1Ti4s6/rKB+Ies1yZwklAQB7s3cFsB9pnuuAqEilW4rF7iPcXZD0Ilzx r2CbSfYioO0kecdF0oklw6rN9/IfHEQBZDasMIA7ua4K0XpOlDA4rnYtghoqu0gA EOwv1FTWMdRpq+s8+e0+br0HgEy8Jyc3f4MTxUvcyqPXvQkLGHf2XOBChcS//zxL OjTURvqSkmCwb0bHDkguc+HIdOEoxMca8nppuTzviacHivs4Jw47lCCjR+BJg058 LCWUTA== 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=fm2; bh=7o+1CzBqN+mDLnxrzBKgI5Xz8byKfGiNbl6EISG0g Gk=; b=ve1BYhHRRNZrlVx8zvWDsiQGR+ni8uyRRzFUIKSKon6IjEMna3NCx92K1 5L7+ZGJ5yvDzmPVFyI5tDsDzCD+iaAnie01cjzpTSW5k6MV88MvcdnkYpxKINyZo dllJvkti41zSIxs6YEMhZUD/SrZg+XLXv1RmVcdK4LyGvr2nAcDwgOjZDdTQECmI Dq7BvYQwInKmJW9BtgI7Pa/vweVN6uMRCAvMwFJrwxUh1gFhg3xFoECZvlhanOxN EfAkxS7Vc1Kkzl2HantyzPHhtS4or2NtYDerp1wf7KdV0qX/g+sBu8wJo6szHVRE 5u+tKOvU/arQ1E2s3bpRBSwOGPhnQ== X-ME-Sender: <xms:M9vOXjWtf5UjkZJjW4JBg5-wsj09-U5xAvylHJF_x4olq8VlLJJWBw> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvgedgudegiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgr lhhonhdrnhgvth X-ME-Proxy: <xmx:M9vOXrl5zEdXWhGXPhSnb7sgIFz0_OWsGtUXk4TGzt0iuMTzTBY__Q> <xmx:M9vOXvZhWOMjbNZonurMHqWlb7u8RLh2-rRa1UwpiI33i--BybT8_w> <xmx:M9vOXuUlUBzLAwTqMQiVesYSGEUdG3oz914tzSHWMI5_iYDxYjFTHw> <xmx:NdvOXgvC0OUeL2iMizOrfS10vf0qEVLPCcLD8McCza3lHlB_JMs_rw> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id ECD423280064; Wed, 27 May 2020 17:27:14 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: Neil Horman <nhorman@tuxdriver.com>, Harini Ramakrishnan <harini.ramakrishnan@microsoft.com> Cc: Fady Bader <fady@mellanox.com>, dev@dpdk.org, Omar Cardona <ocardona@microsoft.com>, Pallavi Kadam <pallavi.kadam@intel.com>, Ranjit Menon <ranjit.menon@intel.com>, dmitry.kozliuk@gmail.com, mdr@ashroe.eu Date: Wed, 27 May 2020 23:27:12 +0200 Message-ID: <3834007.4YYSKOMRdh@thomas> In-Reply-To: <20200527203503.GA1603965@hmswarspite.think-freely.org> References: <AM0PR0502MB4034BCC8160D99C07AA0870EBFB10@AM0PR0502MB4034.eurprd05.prod.outlook.com> <1906091.XQj0qEek43@thomas> <20200527203503.GA1603965@hmswarspite.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] ABI versioning in Windows X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> 27/05/2020 22:35, Neil Horman: > On Wed, May 27, 2020 at 02:50:07PM +0200, Thomas Monjalon wrote: > > +Cc more people > > > > 27/05/2020 12:41, Fady Bader: > > > What should we do with the ABI versioning in Windows ? > > > > I think there are 2 questions here: > > > > 1/ Do we want to maintain ABI compatibility on Windows like we do for Linux and FreeBSD? > > The decision must be clearly documented. > > > My first notion, without any greater thought is "why wouldn't we". ABI > stability is OS agnostic. If a symbol is considered stable, theres no reason > that I can think of that it wouldn't be stable for each OS. Technical reason + no need so far. > > 2/ How do we implement the macros in rte_function_versioning.h for Windows? > > Something needs to be done, otherwise we cannot compile libraries having some function versioning. > > > Can you elaborate on what exactly the issue is here? I presume by your comment > above that visual studio either doesn't support symbol level versioning or > doesn't support versioning at all? I don't know how to implement the macros in rte_function_versioning.h for Windows. > If thats the case, and there is a commitment to make dpdk buildable on windows, > I suppose the only choice is to make a ifdef WINDOWS section of the > rte_function_versioning.h file, and effectively turn all the macros into no-ops. Yes that's the idea. But we still need to implement either BIND_DEFAULT_SYMBOL or MAP_STATIC_SYMBOL to alias the latest function version to the actual function symbol. > The BIND_DEFAULT_SYMBOL macro looks like it could still work, as MSVC has an > alias linker command thats implementable via __pragma, but thats probably all we > can do, unless there is some more robust versioning support that I can't find. What is this pragma? > Note we will also likely need to agument the makefiles/meson files so that the > link stage doesn't pass the version script to the linker Why not using the version script for exported symbols? We are already doing it (.def file generated from .map).