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 73672A0547; Thu, 20 May 2021 20:43:04 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E9DA740143; Thu, 20 May 2021 20:43:03 +0200 (CEST) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by mails.dpdk.org (Postfix) with ESMTP id 4549940041 for ; Thu, 20 May 2021 20:43:03 +0200 (CEST) Received: by mail-lf1-f46.google.com with SMTP id w33so18032693lfu.7 for ; Thu, 20 May 2021 11:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=6eYMR/n6uMfvb8wLnJnOVbToty5e0kR+tBX4DUCLU+g=; b=bjXKiloqJgBJKXneuZhSelAtv8DLmQ0oWWMAZ92gnJMzfagBg/pwA/uDJCK4k2ulQX cXTNRoiNkAHqPioS7gsNgdSr7aV2HRKMVT3lhSfkh4ymel1lbA34CJ/iq5uaBBqHcW2c G142/eRrXc7HYJ5soo9VY1pl/tfS8DJSl6mwM7EX8smGuOdE3jJXcYMCxkR/Sl8FVdfo 0ewckQSjzD88yS4XliELj9KzxdDn+mQZ4drBiTEXRnQYqmR1LMOhBOjo4yJqZL1Wiubr eehEbZ8AxUwbPRuzscEHZ78vx4VUS0RuRKJhDOzuu5BBWO6lNZiD078YCcss9eBBoEgu eUQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=6eYMR/n6uMfvb8wLnJnOVbToty5e0kR+tBX4DUCLU+g=; b=HsAF0L4cSntnEivco5yzw0luZiBL/R7TDIsfB32ZmjeFJ4/XhbUVvKp80zq95nQTMa HXh6QUoFn6+GNkSgXfW0nvzGgncSnaILDgB0Or/qHsBZy2itZSQXBAvnYpelLfAJ3+w8 DYv86aHGacruKY2r0kwCZt9f1f7fbRRJDYfQtfRt/5SuIoD0PBUx9D8s1krH1zf/LUVT X6OwMFHUJmL3XdouZ97dYCry3ZLYpQTkT7FgBK1/8kAS+DsaXYJvGNtzIKwjtnqjbyJl YP0zTkZPa62oi8lOJwCgbZFyJoOiX2r0wMLODchrgbklqtQuYOQuG7KKjLSSr2uO6VDl sWUA== X-Gm-Message-State: AOAM530DsSq4tp45hWmW5Bjm0+R9Gasy28r049znK6tmedgdK40oiEKk n6VLHgu7MS9Jawi5h4zz2al8tHyZypNiGA== X-Google-Smtp-Source: ABdhPJwJnoY8ViGScY/eE8sjoQ6RC8bOV8TYQ2MYny6ZNc6e4GpwnngjNSY31CQ1bIWO6cD1M6/meQ== X-Received: by 2002:a05:6512:2089:: with SMTP id t9mr4216264lfr.257.1621536182474; Thu, 20 May 2021 11:43:02 -0700 (PDT) Received: from localhost.localdomain (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id t13sm382577lji.19.2021.05.20.11.43.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 May 2021 11:43:01 -0700 (PDT) From: Dmitry Kozlyuk To: dev@dpdk.org Cc: Ferruh Yigit , Akhil Goyal , Fiona Trahe , Ashish Gupta , Dmitry Kozlyuk , Khoa To , Ray Kinsella , Neil Horman Date: Thu, 20 May 2021 21:42:54 +0300 Message-Id: <20210520184254.16790-1-dmitry.kozliuk@gmail.com> X-Mailer: git-send-email 2.29.3 In-Reply-To: <20210310235421.23259-1-dmitry.kozliuk@gmail.com> References: <20210310235421.23259-1-dmitry.kozliuk@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-dev] [PATCH v3] doc: announce API changes for Windows compatibility 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 Sender: "dev" Windows system headers define `s_addr`, `min`, and `max` macros which break structure definitions containing fields with one of these names. Undefining those macros would break consumer code that relies on them. Example 1: #include #include struct in_addr addr; /* addr.s_addr = 0; ERROR: s_addr undefined by DPDK */ Example 2: #include #include struct rte_ether_hdr eh; /* eh.s_addr.addr_bytes[0] = 0; ERROR: `addr_s` is a macro */ Commit 6c068dbd9fea ("net: work around s_addr macro on Windows") modified definition of `struct rte_ether_hdr` to avoid the issue. However, the workaround assumes `#define s_addr S_addr.S_un` in Windows headers, which is not a part of official API. It also complicates the definition of `struct rte_ether_hdr`. For `min` and `max`, no workaround seems available. If cryptodev or compressdev is going to be enabled on Windows before 21.11, the only option seems to use a new name on Windows (using #ifdef). It is proposed to rename the conflicting fields on DPDK side, because Win32 API has wider use and is slower and harder to change. Exact new names are left for further discussion. Signed-off-by: Dmitry Kozlyuk Acked-by: Khoa To --- v3: fix typos (Ferruh), remove naming speculation, replace workaround snippet with commit reference. doc/guides/rel_notes/deprecation.rst | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 9584d6bfd7..cc6e8db92c 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -147,3 +147,12 @@ Deprecation Notices * cmdline: ``cmdline`` structure will be made opaque to hide platform-specific content. On Linux and FreeBSD, supported prior to DPDK 20.11, original structure will be kept until DPDK 21.11. + +* net: ``s_addr`` and ``d_addr`` fields of ``rte_ether_hdr`` structure + will be renamed in DPDK 21.11 to avoid conflict with Windows Sockets headers. + +* compressdev: ``min`` and ``max`` fields of ``rte_param_log2_range`` structure + will be renamed in DPDK 21.11 to avoid conflict with Windows Sockets headers. + +* cryptodev: ``min`` and ``max`` fields of ``rte_crypto_param_range`` structure + will be renamed in DPDK 21.11 to avoid conflict with Windows Sockets headers. -- 2.29.3