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 574601C0A5 for ; Fri, 13 Apr 2018 15:58:58 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D1FA221AA1; Fri, 13 Apr 2018 09:58:57 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 13 Apr 2018 09:58:57 -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=ewQlVfe0S1uR/fPe4CfG9zFz8o FZd2FtrzYFAXL7hv0=; b=ivVb1g9RZv8eLj92T43ekQNgcBT/JrNos4dZuN2SCJ baddlhEVTkVZech8qVSB5eyW0zVfunU6ukeGn3wQ4VRp1IsYZMQccFlqmNDkxDDt +vQjqjLsD2JcnLRlQ0X/dzUP/VkVc2Ifd4eEQudQAXZKilwnXEb6IuXj20OVaf9A M= 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=ewQlVf e0S1uR/fPe4CfG9zFz8oFZd2FtrzYFAXL7hv0=; b=Ge5JjpgnU4aZjirAfPB+zW 22agtqxPNlABGQKCQFjrbAzjG+K2a9/tVkWGGlmJoJMOKx+R2k996J/Bp9haNOlx vHBiCHzYkFaVgz5qeysHz4IFQxerMDre4bilb+vdOFS3YeuQKfl4hf1bLGjl1ANc 7WRd+iYcwEfsx+rNEPxsw8SJ97aMtH8aIFHzJ3b2d0DwMIU4mkdSfBH+rfY3SpqL 134uJT9/V1bAo6Fb17Q83PNh6lM8rbvJ4Iq7ZjySR4extbFIRpkjlKZIJyxt/eNn j3/N3DZQNy2ijbnxsbYVIfarLwVO/Hc5GzBugJv33Js7G2lLFKzeT2ELZCQpCvYA == 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 33290E442C; Fri, 13 Apr 2018 09:58:57 -0400 (EDT) From: Thomas Monjalon To: "Burakov, Anatoly" Cc: dev@dpdk.org, Shahaf Shuler Date: Fri, 13 Apr 2018 15:58:56 +0200 Message-ID: <507876726.mBf8imolCA@xps> In-Reply-To: References: <20180412133422.104155-1-shahafs@mellanox.com> <23085973.mySOohilc8@xps> 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: Fri, 13 Apr 2018 13:58:58 -0000 13/04/2018 15:37, Burakov, Anatoly: > On 13-Apr-18 2:08 PM, Thomas Monjalon wrote: > > 13/04/2018 11:11, Burakov, Anatoly: > >> On 13-Apr-18 12:39 AM, Thomas Monjalon wrote: > >>> 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 ? > >>> > >> > >> Well, technically, yes, we could. There is one function that uses a > >> VFIO-specific struct definition: > >> > >> int rte_vfio_setup_device(const char *sysfs_base, const char *dev_addr, > >> int *vfio_dev_fd, struct vfio_device_info *device_info); > >> > >> I'm sure we can work around that. > > > > > > Removing dummy prototypes need, would be a nicer fix. > > > > OK. Shahaf, will you submit a v2 with this, or should i do it? I think > it should be just a matter of #ifndef VFIO_PRESENT //define > vfio_device_info struct #endif - this should take care of the problem of > hiding the function definitions. > > FreeBSD will also need to be adjusted to remove dummy prototypes. I think you are more familiar with VFIO than any of us. It is better to let you do, think about the implications and do the tests. Thanks :)