From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by dpdk.org (Postfix) with ESMTP id 7FB451B112 for ; Wed, 27 Mar 2019 00:54:50 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 35FD54607; Tue, 26 Mar 2019 19:54:49 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 26 Mar 2019 19:54:49 -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=mesmtp; bh=pAT5yw7PjsYQDLxdfzakzRhbcIuiZQWtXeouKbtGgek=; b=hA59GA/lz3mY Avonh5L10Om8msp9UkELDuknWluDY5zJ1UyCurYIO2B10z04DgFIlqhsUJPre0hr 1UF2hm5yot37GGx9Quxj12fEsJjnlky1GdGiI0YzEMHO0oijDgp949cYD/hRZO/h HxCI0LWxH/h/btz2nW9LPB7+czAbJBQ= 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=pAT5yw7PjsYQDLxdfzakzRhbcIuiZQWtXeouKbtGg ek=; b=oicW10uVy2P+jVnZTP4Heipo0B4WNPnpUDPk3Myd00u2ctuO1aTYGQ8sy 5nF8SwR3b0gf/h2Z/z01jXbMdpCL0YeHyNaT7E7hlRnj9OrWgSBXWnaPTB8kRbKC 2Akw9XQeCj7l/r5JVNHcWRqrMuYkquz0olBifxTf/uKR27QLhztTPffA3VlnOPAT gv9SBHbXeVOBpTn/CnJ+ORBwItqT7/VjmATnbRpq46g7HckXlmnPtc/OTbYtcMvG iWEHr2wsHaAG2ZC1uOPbh3Rpez/BlPZOFsS+7nhH7LDcYtlJ4z+txm5zdt077t0Y YmELIHsTeGSQQ/gXltifiPf+06NJA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrkedugddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucffoh hmrghinhepfhhrvggvuggvshhkthhophdrohhrghdpghhithhhuhgsrdgtohhmnecukfhp peejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhhoh hmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 35B09E4841; Tue, 26 Mar 2019 19:54:47 -0400 (EDT) From: Thomas Monjalon To: Jeff Shaw Cc: Stephen Hemminger , Anand Rawat , dev@dpdk.org, pallavi.kadam@intel.com, ranjit.menon@intel.com, bruce.richardson@intel.com Date: Wed, 27 Mar 2019 00:54:45 +0100 Message-ID: <1563831.Q7rLLWRHia@xps> In-Reply-To: <20190326234359.GA86266@ae13-28.jf.intel.com> References: <20190306041634.12976-1-anand.rawat@intel.com> <2223434.7BpSH3hZxr@xps> <20190326234359.GA86266@ae13-28.jf.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v5 4/8] eal: sys/queue.h implementation for windows 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: , X-List-Received-Date: Tue, 26 Mar 2019 23:54:50 -0000 27/03/2019 00:43, Jeff Shaw: > On Wed, Mar 27, 2019 at 12:00:49AM +0100, Thomas Monjalon wrote: > > 26/03/2019 23:34, Jeff Shaw: > > > On Tue, Mar 26, 2019 at 11:23:50PM +0100, Thomas Monjalon wrote: > > > > 26/03/2019 22:54, Jeff Shaw: > > > > > On Tue, Mar 26, 2019 at 10:47:54PM +0100, Thomas Monjalon wrote: > > > > > > 26/03/2019 22:14, Jeff Shaw: > > > > > > > On Tue, Mar 26, 2019 at 09:52:57PM +0100, Thomas Monjalon wrote: > > > > > > > > Even better would be to get it as a dependency outside of DPDK. > > > > > > > > Where this code come from? > > > > > > > > How other projects on Windows get it? > > > > > > > > > > > > > > It comes from FreeBSD 12.0, specifically > > > > > > > https://github.com/freebsd/freebsd/blob/releng/12.0/sys/sys/queue.h > > > > > > > > > > > > > > It has been modified such that only the parts used by DPDK (i.e. TAILQ) are > > > > > > > implemented. The other stuff has been deleted. Windows does not have sys/queue.h, > > > > > > > so we reproduce it here. > > > > > > > > > > > > > > Would it better to have this as a dependency outside of DPDK? I think pulling a file > > > > > > > from the internet and applying a patch (where we'd have to maintain a patch file > > > > > > > inside of DPDK's repo anyway) would be overkill when we just need a few lines of > > > > > > > code that will change very infrequently. > > > > > > > > > > > > We already try to get the libbsd dependency on Linux. > > > > > > Why not mandate libbsd for Windows? > > > > > > It has this header file and a lot more: > > > > > > https://gitlab.freedesktop.org/libbsd/libbsd/blob/master/include/bsd/sys/queue.h > > > > > > > > > > > > Relying on libbsd may avoid copying other files for Windows port. > > > > > > > > > > I like that idea, though it doesn't look like libbsd builds on Windows, do you > > > > > know of a Windows version or one that doesn't depend on autotools to build? > > > > > > > > It seems libbsd is not packaged for Windows. > > > > May be worth to ask opinions to libbsd maintainers. > > > > > > > > Please could you list which other headers are required for the Windows port? > > > > > > For helloworld the only one is sys/queue.h. > > > > > > The dpdk-draft-windows repo has at least these (non-empty) ones: > > > dirent.h > > > getopt.h > > > net/ethernet.h > > > net/socket.h > > > netinet/in.h > > > netinet/tcp.h > > > pthread.h > > > rand48.h > > > sched.h > > > sys/_iovec.h > > > sys/_sockaddr_storage.h > > > sys/_termios.h > > > sys/_types.h > > > sys/cdefs.h > > > sys/mman.h > > > sys/netbsd/queue.h > > > sys/queue.h > > > sys/sysctl.h > > > syslog.h > > > termios.h > > > unistd.h > > > > > > There will likely be more as more libraries are identified with dependencies on UNIX-like > > > headers. > > > > I would like we find a good solution for these headers. > > I agree. I think the EAL is supposed to do this, however the current implementation generally > assums a UNIX OS under the EAL. The libbsd might be a possiblity. Yes, EAL is supposed to be the layer hiding the OS specifics. It would be interesting to check how much libbsd may help EAL. > > How other cross-platform projects are getting such dependencies? > > One example is Python. I just briefly reviewed the code and they go through great lengths to > abstract the OS and implement custom, OS independent layers wherever required (e.g. sockets, > getopt). See Modules/posixmodule.c for a 14K LOC example. > > Another example is Nginx. The underlying OS is always abstracted with disparate implementations > for, e.g. unix & windows. See src/os/unix and src/os/win32. An example is the "socket()" call > on unix, nginx "core" would call "ngx_socket()" which is a macro that is defined to use > "WSASocketW" on windows, and "socket" on unix. Yes we may need to introduce more wrappers. > > Is Cygwin a solution? > > I think the goal is to be a native Windows application. Yes From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 0ECF6A05D3 for ; Wed, 27 Mar 2019 00:54:52 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 11C891B1F5; Wed, 27 Mar 2019 00:54:52 +0100 (CET) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by dpdk.org (Postfix) with ESMTP id 7FB451B112 for ; Wed, 27 Mar 2019 00:54:50 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 35FD54607; Tue, 26 Mar 2019 19:54:49 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 26 Mar 2019 19:54:49 -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=mesmtp; bh=pAT5yw7PjsYQDLxdfzakzRhbcIuiZQWtXeouKbtGgek=; b=hA59GA/lz3mY Avonh5L10Om8msp9UkELDuknWluDY5zJ1UyCurYIO2B10z04DgFIlqhsUJPre0hr 1UF2hm5yot37GGx9Quxj12fEsJjnlky1GdGiI0YzEMHO0oijDgp949cYD/hRZO/h HxCI0LWxH/h/btz2nW9LPB7+czAbJBQ= 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=pAT5yw7PjsYQDLxdfzakzRhbcIuiZQWtXeouKbtGg ek=; b=oicW10uVy2P+jVnZTP4Heipo0B4WNPnpUDPk3Myd00u2ctuO1aTYGQ8sy 5nF8SwR3b0gf/h2Z/z01jXbMdpCL0YeHyNaT7E7hlRnj9OrWgSBXWnaPTB8kRbKC 2Akw9XQeCj7l/r5JVNHcWRqrMuYkquz0olBifxTf/uKR27QLhztTPffA3VlnOPAT gv9SBHbXeVOBpTn/CnJ+ORBwItqT7/VjmATnbRpq46g7HckXlmnPtc/OTbYtcMvG iWEHr2wsHaAG2ZC1uOPbh3Rpez/BlPZOFsS+7nhH7LDcYtlJ4z+txm5zdt077t0Y YmELIHsTeGSQQ/gXltifiPf+06NJA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrkedugddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucffoh hmrghinhepfhhrvggvuggvshhkthhophdrohhrghdpghhithhhuhgsrdgtohhmnecukfhp peejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhhoh hmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 35B09E4841; Tue, 26 Mar 2019 19:54:47 -0400 (EDT) From: Thomas Monjalon To: Jeff Shaw Cc: Stephen Hemminger , Anand Rawat , dev@dpdk.org, pallavi.kadam@intel.com, ranjit.menon@intel.com, bruce.richardson@intel.com Date: Wed, 27 Mar 2019 00:54:45 +0100 Message-ID: <1563831.Q7rLLWRHia@xps> In-Reply-To: <20190326234359.GA86266@ae13-28.jf.intel.com> References: <20190306041634.12976-1-anand.rawat@intel.com> <2223434.7BpSH3hZxr@xps> <20190326234359.GA86266@ae13-28.jf.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v5 4/8] eal: sys/queue.h implementation for windows 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" Message-ID: <20190326235445.5phW9I_XpjQtg3Amw7TYWMQxvTCLEEXZsWGotF6yomQ@z> 27/03/2019 00:43, Jeff Shaw: > On Wed, Mar 27, 2019 at 12:00:49AM +0100, Thomas Monjalon wrote: > > 26/03/2019 23:34, Jeff Shaw: > > > On Tue, Mar 26, 2019 at 11:23:50PM +0100, Thomas Monjalon wrote: > > > > 26/03/2019 22:54, Jeff Shaw: > > > > > On Tue, Mar 26, 2019 at 10:47:54PM +0100, Thomas Monjalon wrote: > > > > > > 26/03/2019 22:14, Jeff Shaw: > > > > > > > On Tue, Mar 26, 2019 at 09:52:57PM +0100, Thomas Monjalon wrote: > > > > > > > > Even better would be to get it as a dependency outside of DPDK. > > > > > > > > Where this code come from? > > > > > > > > How other projects on Windows get it? > > > > > > > > > > > > > > It comes from FreeBSD 12.0, specifically > > > > > > > https://github.com/freebsd/freebsd/blob/releng/12.0/sys/sys/queue.h > > > > > > > > > > > > > > It has been modified such that only the parts used by DPDK (i.e. TAILQ) are > > > > > > > implemented. The other stuff has been deleted. Windows does not have sys/queue.h, > > > > > > > so we reproduce it here. > > > > > > > > > > > > > > Would it better to have this as a dependency outside of DPDK? I think pulling a file > > > > > > > from the internet and applying a patch (where we'd have to maintain a patch file > > > > > > > inside of DPDK's repo anyway) would be overkill when we just need a few lines of > > > > > > > code that will change very infrequently. > > > > > > > > > > > > We already try to get the libbsd dependency on Linux. > > > > > > Why not mandate libbsd for Windows? > > > > > > It has this header file and a lot more: > > > > > > https://gitlab.freedesktop.org/libbsd/libbsd/blob/master/include/bsd/sys/queue.h > > > > > > > > > > > > Relying on libbsd may avoid copying other files for Windows port. > > > > > > > > > > I like that idea, though it doesn't look like libbsd builds on Windows, do you > > > > > know of a Windows version or one that doesn't depend on autotools to build? > > > > > > > > It seems libbsd is not packaged for Windows. > > > > May be worth to ask opinions to libbsd maintainers. > > > > > > > > Please could you list which other headers are required for the Windows port? > > > > > > For helloworld the only one is sys/queue.h. > > > > > > The dpdk-draft-windows repo has at least these (non-empty) ones: > > > dirent.h > > > getopt.h > > > net/ethernet.h > > > net/socket.h > > > netinet/in.h > > > netinet/tcp.h > > > pthread.h > > > rand48.h > > > sched.h > > > sys/_iovec.h > > > sys/_sockaddr_storage.h > > > sys/_termios.h > > > sys/_types.h > > > sys/cdefs.h > > > sys/mman.h > > > sys/netbsd/queue.h > > > sys/queue.h > > > sys/sysctl.h > > > syslog.h > > > termios.h > > > unistd.h > > > > > > There will likely be more as more libraries are identified with dependencies on UNIX-like > > > headers. > > > > I would like we find a good solution for these headers. > > I agree. I think the EAL is supposed to do this, however the current implementation generally > assums a UNIX OS under the EAL. The libbsd might be a possiblity. Yes, EAL is supposed to be the layer hiding the OS specifics. It would be interesting to check how much libbsd may help EAL. > > How other cross-platform projects are getting such dependencies? > > One example is Python. I just briefly reviewed the code and they go through great lengths to > abstract the OS and implement custom, OS independent layers wherever required (e.g. sockets, > getopt). See Modules/posixmodule.c for a 14K LOC example. > > Another example is Nginx. The underlying OS is always abstracted with disparate implementations > for, e.g. unix & windows. See src/os/unix and src/os/win32. An example is the "socket()" call > on unix, nginx "core" would call "ngx_socket()" which is a macro that is defined to use > "WSASocketW" on windows, and "socket" on unix. Yes we may need to introduce more wrappers. > > Is Cygwin a solution? > > I think the goal is to be a native Windows application. Yes