From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id E42FF4C9D for ; Fri, 21 Sep 2018 16:49:42 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9060721F00; Fri, 21 Sep 2018 10:49:42 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 21 Sep 2018 10:49:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=qg34E/PW9SK42hlf6dKYLU9ZhP 4671C820O1utCVgP8=; b=YXY+LeqOkDy7xwsvpeFHzoCHI4hMhzwxSWD4CZF5gT MyIPnPdaRKIiN/UbA0FsAMPA0ffzxgYtrWsRMJ76h3/375S5BDw//9y/Qx/Hr97L RSaIOFS0VVH9ojNXuDkQQlhsujT/ZNzCVVD7+tlHysdWyujYvuEy+sffVDmftNqt Q= 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-sender:x-me-sender:x-sasl-enc; s=fm3; bh=qg34E/ PW9SK42hlf6dKYLU9ZhP4671C820O1utCVgP8=; b=I+X2zjyYfTyFOf1aThoNZg VEpvLDY7p2olbt2E4BCTm4+8t/V4cs/Sbq5wqKs5jVcjfAxOIZd+EE26Bb8nzTMB z20OnVNHIOZe9k0hVZwO8I1PkHhzZC7STExT444zjr6VRYXYQmYY9fnTVwmR17KN 4tPVrSxoYw3qOcH/i94fqqHX3rb6uH4583b5QHfDeWW2acQCUSWXPZvQSkMXQuTz pUaVQx6Fitk/M4ooh2MuNADxqvMQLMpd60b3UXWiPO2mwsjJqQcRGFVozD5KC06N ViuniiQp6j28+ZMOzLU0ag1H8GvsA9BWZnBe4h1E74BhdUrPWL+u6IQ8ulCu7MXA == X-ME-Proxy: X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 6DBC9102E4; Fri, 21 Sep 2018 10:49:40 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit Cc: Rahul Lakkireddy , Wenzhuo Lu , Qi Zhang , Xiao Wang , Konstantin Ananyev , Rasesh Mody , Harish Patil , Shahed Shaikh , Yong Wang , dev@dpdk.org Date: Fri, 21 Sep 2018 16:49:39 +0200 Message-ID: <5551506.CmDVCAXTxv@xps> In-Reply-To: References: <20180920001853.23454-1-thomas@monjalon.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] drivers/net: do not redefine bool 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: Fri, 21 Sep 2018 14:49:43 -0000 21/09/2018 15:47, Ferruh Yigit: > On 9/20/2018 1:18 AM, Thomas Monjalon wrote: > > When trying to include stdbool.h in DPDK base headers, there are a lot > > of conflicts with drivers which redefine bool/true/false > > in their compatibility layer. > > > > It is fixed by including stdbool.h in these drivers. > > Some errors with usage of bool type are also fixed in some drivers. > > > > Note: the driver qede has a surprising mix of bool and int: > > (~p_iov->b_pre_fp_hsi & ETH_HSI_VER_MINOR) > > where the first variable is boolean and the version is a number. > > It is replaced by > > !p_iov->b_pre_fp_hsi > > > > Signed-off-by: Thomas Monjalon > > --- > > drivers/net/cxgbe/cxgbe_compat.h | 2 +- > > drivers/net/e1000/base/e1000_osdep.h | 5 +---- > > drivers/net/fm10k/base/fm10k_osdep.h | 8 +------- > > drivers/net/fm10k/fm10k_ethdev.c | 4 ++-- > > drivers/net/ixgbe/base/ixgbe_osdep.h | 6 +----- > > drivers/net/ixgbe/ixgbe_ethdev.c | 16 +++++++++------- > > drivers/net/ixgbe/ixgbe_rxtx.c | 2 +- > > drivers/net/qede/base/bcm_osal.h | 6 ++---- > > drivers/net/qede/base/ecore_vf.c | 3 +-- > > drivers/net/qede/qede_ethdev.c | 2 +- > > drivers/net/vmxnet3/base/vmxnet3_osdep.h | 3 ++- > > 11 files changed, 22 insertions(+), 35 deletions(-) > > <...> > > > @@ -35,6 +35,7 @@ > > #ifndef _E1000_OSDEP_H_ > > #define _E1000_OSDEP_H_ > > > > +#include > > #include > > #include > > #include > > @@ -87,7 +88,6 @@ typedef int64_t s64; > > typedef int32_t s32; > > typedef int16_t s16; > > typedef int8_t s8; > > -typedef int bool; > > > > #define __le16 u16 > > #define __le32 u32 > > @@ -192,7 +192,4 @@ static inline uint16_t e1000_read_addr16(volatile void *addr) > > #define ETH_ADDR_LEN 6 > > #endif > > > > -#define false FALSE > > -#define true TRUE > > - > > It is too much hassle to update Intel base driver code. It is not really base driver code. It was agreed that *_osdep.h can be modified: http://git.dpdk.org/dpdk/tree/drivers/net/ixgbe/base/README#n56 > What would happen if not > include stdbool and keep define for base code updates? Will it break build for > applications? The problem is not applications, but using stdbool in DPDK headers.