From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 530A12C2B for ; Thu, 29 Mar 2018 19:01:20 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E06E120F29; Thu, 29 Mar 2018 13:01:19 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 29 Mar 2018 13:01:19 -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=tAZe+yCz0QZaZRC0607RzF2QcM y1h/ZqflX02nQMD3U=; b=LaDmq0YIkSmgNNNwCYKXkJZ3nwRoBoOaCYf5x4gXm4 2PK2A0dKIFLTblbkfH7YeVNLytXMeI1eO6mXoKiZ8+j2+UWZeokrzGXXDvBAOdUG sf7dyGWPE4xVgRr9a+yP5/dVzP+PNgBxj4Td13Tg+qBfYI0bHU71stTOl7sSXlsx g= 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=tAZe+y Cz0QZaZRC0607RzF2QcMy1h/ZqflX02nQMD3U=; b=DvOB0lL9fFO54PrhNN3eLy Ya7lw6SqTD4XSzxgtoi9OK6ygDfZ0Xp62Tfuw5zS8KcB3JlzUolasGI56n4nuQO8 gJkzcysol2u+MCVpnuWZcH53pMHndo3EAZsZ4EzzWVVSQC90vtkb0trwOeAk5EVo Dtnm2Ziha56+3B2OHXmBb+OWBWDJ1NMcm6n3HDJJihoUFJOel9scEYYPXZlF/yoi 7dgG9t3iRkPuyBeuCuODY0YVH0ECuXts0MjQxGDXAOc1cFGpuuKIntBKzB31YXmq H6naZBWJp5eZ/5LmmtnbgnH/orbpTBGvMqh9nrgU7RgTec9UZ/GSC4XI5datvfzQ == 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 2FAF21025C; Thu, 29 Mar 2018 13:01:19 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit Cc: hemant.agrawal@nxp.com, dev@dpdk.org Date: Thu, 29 Mar 2018 19:01:18 +0200 Message-ID: <1680117.05lWP9jXLg@xps> In-Reply-To: <0a59c197-0331-a122-f997-b8a77b39e01b@intel.com> References: <20180329153931.26351-1-thomas@monjalon.net> <2419180.MvykWTCLKm@xps> <0a59c197-0331-a122-f997-b8a77b39e01b@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] mk: fix kernel modules build dependency 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, 29 Mar 2018 17:01:20 -0000 29/03/2018 18:50, Ferruh Yigit: > On 3/29/2018 5:43 PM, Thomas Monjalon wrote: > > 29/03/2018 18:38, Ferruh Yigit: > >> On 3/29/2018 5:32 PM, Thomas Monjalon wrote: > >>> 29/03/2018 17:48, Ferruh Yigit: > >>>> On 3/29/2018 4:39 PM, Thomas Monjalon wrote: > >>>>> Some kernel modules may need some header files to be "installed" > >>>>> in the build directory. > >>>>> > >>>>> When running multiple threads of make, kernel modules can try to > >>>>> be compiled before the lib headers are ready: > >>>>> make -j3 > >>>>> kernel/linux/kni/kni_misc.c:19:37: fatal error: > >>>>> exec-env/rte_kni_common.h: No such file or directory > >>>> > >>>> Is there a reason to keep header in eal when module itself moved into kernel? > >>> > >>> It seems you missed my comment below: > >>> > >>> On a related note, this header file > >>> lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h > >>> could be moved to lib/librte_kni/ > >>> Opinion? > >> > >> Ahh, yes we are saying same thing. > >> But not sure if it should go under lib/librte_kni/ or kernel/linux/kni/? > >> I lean to kernel/linux/kni/. > > > > Why in kernel/? > > > > Logically, kernel/ depends on lib/ but not the reverse. > > > > And regarding the licensing, we avoid BSD files in Linux modules. > > From functionality point of view, module provides the functionality and it > should provide the header, this can be all subjective tough :) > > Or in other words, if you have the kernel module, you can write another piece of > userspace application (without using librte_kni) and it will be functional. > But if you have the librte_kni only, it won't be functional on its own. > > Providing header with kernel enables other userspace app to user KNI. So you are saying we should reverse the dependency? It would mean moving all headers used by kernel modules in kernel/ directory: - rte_pci_dev_features.h \- rte_pci_dev_feature_defs.h - rte_kni_common.h \- rte_common.h Are you sure?