From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 137751C111 for ; Fri, 13 Apr 2018 01:40:01 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 86C50212A3; Thu, 12 Apr 2018 19:40:00 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 12 Apr 2018 19:40:00 -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=GQZAU6mXI+IYFosdj/RxQOJM5A d2dJlaWNfdJf7WiG4=; b=bR2CoFnSq0B891A468hLbjmnVaIfr/XszhLsYbmfEU QGAynUGK6QsdvcLGIJxWFLqVmqoz6d/DDtr1UZwnmcA6LD0ST5VOHAjzoCJcoUjw R0k+0gL2aslw/AUziVC3l++o6cIBpy6/UAP0ulUQDaptjaOEOK/wFZzKj3FZspxQ w= 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=fm2; bh=GQZAU6 mXI+IYFosdj/RxQOJM5Ad2dJlaWNfdJf7WiG4=; b=REufio6YjLnmbd0/HUzEF8 tMwFl9W49FSPOStnR2FrsnZaY/MAhhbgu2fCXxRrmTFBpaU9O7zeqZQqgtgiQXDy xBlHJIrUUPxBXJVIx7V77Fesh5UoKmkG+TDC2Er9JkwrPWzeMJtpkeHa4gByeto8 RSvjOJ27v1vWrkU9v3IJM394HoJPPiRcps9Re9T3XWW3fSLCyAX4ohDbQ4g6xg8i y3ZBfkVYtH5flKZFUUqzw3zgysLllNYlYi/+YxJGfESBMsfvmaO/GASvYN6fyn2Z 2oMiJ/94ZvS5lJkH+ZWODKhsguswSxkqQXGkD+pAH1U9QN2GN420W9mxEEo7AgxQ == 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 CE4BDE442C; Thu, 12 Apr 2018 19:39:59 -0400 (EDT) From: Thomas Monjalon To: "Burakov, Anatoly" Cc: dev@dpdk.org, Shahaf Shuler Date: Fri, 13 Apr 2018 01:39:57 +0200 Message-ID: <7325634.395TUUszRC@xps> In-Reply-To: References: <20180412133422.104155-1-shahafs@mellanox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] eal: fix compilation without VFIO 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: Thu, 12 Apr 2018 23:40:01 -0000 12/04/2018 16:13, Burakov, Anatoly: > On 12-Apr-18 2:34 PM, Shahaf Shuler wrote: > > a compilation error occurred when compiling with CONFIG_RTE_EAL_VFIO=n > > > > == Build lib/librte_eal/linuxapp/eal > > CC eal_vfio.o > > /download/dpdk/lib/librte_eal/linuxapp/eal/eal_vfio.c:1535:1: error: no > > previous prototype for 'rte_vfio_dma_map' [-Werror=missing-prototypes] > > rte_vfio_dma_map(uint64_t __rte_unused vaddr, __rte_unused uint64_t > > iova, > > ^ > > /download/dpdk/lib/librte_eal/linuxapp/eal/eal_vfio.c:1542:1: error: no > > previous prototype for 'rte_vfio_dma_unmap' [-Werror=missing-prototypes] > > rte_vfio_dma_unmap(uint64_t __rte_unused vaddr, uint64_t __rte_unused > > iova, > > ^ > > > > As there is no use for those dummy functions without VFIO removing them > > completely. > > These functions are part of public API, like rest of functions in this > header. They're in the map file. Should we perhaps go the BSD way and > provide EAL with dummy prototypes as well? See bsdapp/eal/eal.c:763 onwards. Why using dummy prototypes? Because the prototypes in rte_vfio.h are under #ifdef VFIO_PRESENT ? Is it possible to always define the prototypes in rte_vfio.h ?