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 3F7FEA0350; Tue, 30 Jun 2020 01:56:26 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 250CA1BF7F; Tue, 30 Jun 2020 01:56:25 +0200 (CEST) Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) by dpdk.org (Postfix) with ESMTP id 263061BF7D for ; Tue, 30 Jun 2020 01:56:23 +0200 (CEST) Received: by mail-lj1-f193.google.com with SMTP id d17so5669395ljl.3 for ; Mon, 29 Jun 2020 16:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=zFpj6O0CF0qxNApshHvH1TbzHHDMzsci54kXTcA+c90=; b=Q8d7IErpLmlAjRjqf13PBlGQ95XfX+JgQzpHRMFbYvcbmbZbyE+4+MVVqLjPwagn31 3LRWvID/GHK3ZUkttmukE48ZBTZngqLpR+RFJN7dhY+eb6Yd9VX0r8UBb+f1E4RI6Vdj S6hQsAKdvXEA80c1/DJ+KUi3hLAw4O1kgswoz+7H4DdyRrBZVyqZCQN/2fmcfic6S+wc occpBZxJ/qj8IavpG68I5SmR//sS4rEpvZGGa/FMIkajkd0ojET41e1kQ1JYOtElWaxH VMAagFpOosq+uPI17E8M9wg3DPeiGFBqa5H5IWobZJeXwPkRi/EDANAH5kWNIVKEAa8t B0uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=zFpj6O0CF0qxNApshHvH1TbzHHDMzsci54kXTcA+c90=; b=Xo17p/w1LEJKmpWk9ompkSXBpDhsWQzOjKZQsDY/UVUY6WxUtLuVQ4o0VDgBOsms3m DqYsFpYPl4bJEBieEpaY7nKIMOoxhs/I1dCSWikYASkKSFgiwaQHydr06+i628z0XmOx hDB8jxyIk2sZhvRQaC2lSpf8SLP496aCwhLnGMPHtVgnQ34l9F71b/Iew+CdPg3+nQsC KdJUM5Rs2UvzmXxIwEaBKDjVIFZwil9KsWPjZUh87BKkLd5LEXnPq5gk1pJPhegg6Maf dL6cLyZoBqUkS9eCWao2Ck1b9eJFVCR+sKo8SAL4CgRHHX+rleL0fcETqsQEZzQ6ReIN 0rDg== X-Gm-Message-State: AOAM5337/jDFCg8rqB/UPH0kf43GGlmMRtB6qfvn01ODC+OLBL/HGbCb TVgD44EYe0C05UI7d0ySph4= X-Google-Smtp-Source: ABdhPJwO7bQOZszJ71X4xmJFzTaOmxou5oa+CWnFjiTUMpZYD1EmN5pS55bgkL0YyJXd9amcm4GckQ== X-Received: by 2002:a2e:a544:: with SMTP id e4mr9942614ljn.264.1593474982506; Mon, 29 Jun 2020 16:56:22 -0700 (PDT) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id q1sm262345lji.71.2020.06.29.16.56.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jun 2020 16:56:21 -0700 (PDT) Date: Tue, 30 Jun 2020 02:56:20 +0300 From: Dmitry Kozlyuk To: Tal Shnaiderman Cc: Ranjit Menon , Fady Bader , "dev@dpdk.org" , Dmitry Malloy , Narcisa Ana Maria Vasile , Thomas Monjalon , Olivier Matz Message-ID: <20200630025620.241e6d54@sovereign> In-Reply-To: References: <20200620210511.13134-1-dmitry.kozliuk@gmail.com> <20200620210511.13134-7-dmitry.kozliuk@gmail.com> <8b908479-d64c-495d-3a69-de561f2608e8@intel.com> <20200629104239.7c0d3d68@sovereign> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 6/7] cmdline: support 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" On Mon, 29 Jun 2020 08:12:51 +0000, Tal Shnaiderman wrote: > > From: Dmitry Kozlyuk > > Subject: Re: [dpdk-dev] [PATCH 6/7] cmdline: support Windows > > > > On Sun, 28 Jun 2020 23:23:11 -0700, Ranjit Menon wrote: > > > On 6/28/2020 7:20 AM, Fady Bader wrote: > > > > Hi Dmitry, > > > > I'm trying to run test-pmd on Windows and I ran into this error with > > cmdline. > > > > > > > > The error log message is : > > > > In file included from ../app/test-pmd/cmdline_flow.c:23: > > > > ..\lib\librte_cmdline/cmdline_parse_num.h:24:2: error: 'INT64' > > redeclared as different kind of symbol > > > > INT64 > > > > > > > > In file included from C:/mingw-w64/x86_64/mingw64/x86_64-w64- > > mingw32/include/winnt.h:150, > > > > from C:/mingw-w64/x86_64/mingw64/x86_64-w64- > > mingw32/include/minwindef.h:163, > > > > from C:/mingw-w64/x86_64/mingw64/x86_64-w64- > > mingw32/include/windef.h:8, > > > > from C:/mingw-w64/x86_64/mingw64/x86_64-w64- > > mingw32/include/windows.h:69, > > > > from ..\lib/librte_eal/windows/include/rte_windows.h:22, > > > > from ..\lib/librte_eal/windows/include/pthread.h:20, > > > > from ..\lib/librte_eal/include/rte_per_lcore.h:25, > > > > from ..\lib/librte_eal/include/rte_errno.h:18, > > > > from ..\lib\librte_ethdev/rte_ethdev.h:156, > > > > from ../app/test-pmd/cmdline_flow.c:18: > > > > C:/mingw-w64/x86_64/mingw64/x86_64-w64- > > mingw32/include/basetsd.h:32:44: note: previous declaration of 'INT64' was > > here > > > > __MINGW_EXTENSION typedef signed __int64 INT64,*PINT64; > > > > > > > > The same error is for the other types defined in cmdline_numtype. > > > > > > > > This problem with windows.h is popping in many places and some of > > > > them are cmdline and test-pmd and librte_net. > > > > We should find a way to exclude windows.h from the unneeded places, > > > > is there any suggestions on how it can be done ? > > > > > > We ran into this same issue when working with the code that is on the > > > draft repo. > > > > > > The issue is that UINT8, UINT16, INT32, INT64 etc. are reserved types > > > in Windows headers for integer types. We found that it is easier to > > > change the enum in cmdline_parse_num.h than try to play with the > > > include order of headers. AFAIK, the enums were only used to determine > > > the type in a series of switch() statements in librte_cmdline, so we > > > simply renamed the enums. Not sure, if that will be acceptable here. > > > > +1 for renaming enum values. It's not a problem of librte_cmdline itself > > +but a > > problem of its consumption on Windows, however renaming enum values > > doesn't break ABI and winn make librte_cmdline API "namespaced". > > > > I don't see a clean way not to expose windows.h, because pthread.h > > depends on it, and if we hide implementation, librte_eal would have to > > export pthread symbols on Windows, which is a hack (or is it?). > > test_pmd redefine BOOLEAN and PATTERN in the index enum, I'm not sure how many more conflicts we will face because of this huge include. > > Also, DPDK applications will inherit it unknowingly, not sure if this is common for windows libraries. I never hit these particular conflicts, but you're right that there will be more, e.g. I remember particularly nasty clashes in failsafe PMD, unrelated to cmdline token names. We could take the same approach as with networking headers: copy required declarations instead of including them from SDK. Here's a list of what pthread.h uses: CloseHandle CreateThread DeleteSynchronizationBarrier EnterSynchronizationBarrier GetThreadAffinityMask InitializeSynchronizationBarrier OpenThread SetPriorityClass SetThreadAffinityMask SetThreadPriority TerminateThread Windows has strict compatibility policy, so prototypes are unlikely to ever change. None of the used functions takes string parameters, thus not affected by A/W macros. Looks a bit messy, but it's limited in scope at least. An external pthread library would solve the problem, but as I've reported earlier, I failed to find a good one: [1] and [3] are tied to MinGW, although of high quality, [2] seems outdated. [1]: Wnpthreads: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-libraries/winpthreads/ [2] pthreads-win32: https://sourceware.org/pthreads-win32/ [3] mcfgthread: https://github.com/lhmouse/mcfgthread -- Dmitry Kozlyuk