From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Hemant Agrawal <hemant.agrawal@nxp.com>,
Thomas Monjalon <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] mk: fix kernel modules build dependency
Date: Thu, 29 Mar 2018 19:28:35 +0100 [thread overview]
Message-ID: <16136f8e-332f-3b96-21ce-ad05a94c1a54@intel.com> (raw)
In-Reply-To: <AM2PR04MB0753736E3AE764B2BF7D704189A20@AM2PR04MB0753.eurprd04.prod.outlook.com>
On 3/29/2018 7:12 PM, Hemant Agrawal wrote:
>> -----Original Message-----
>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>> Sent: Thursday, March 29, 2018 10:31 PM
>> To: Ferruh Yigit <ferruh.yigit@intel.com>
>> Cc: Hemant Agrawal <hemant.agrawal@nxp.com>; dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] mk: fix kernel modules build dependency
>> Importance: High
>>
>> 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?
>>
> I agree that ideologically the kernel modules shall be self sufficient.
> However, given the dpdk structure, my original intention was to have userspace self sufficient. The kernel modules may depend on userspace.
Overall agree to make userspace self sufficient, it makes builds more stable.
Specific to librte_kni, it is kind wrapper to kni module, so functionally it is
OK to make librte_kni dependent to kni module, but not sure from build point of
view.
>
> However, no strong opinion either way.
>
next prev parent reply other threads:[~2018-03-29 18:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-29 15:39 Thomas Monjalon
2018-03-29 15:48 ` Ferruh Yigit
2018-03-29 16:32 ` Thomas Monjalon
2018-03-29 16:38 ` Ferruh Yigit
2018-03-29 16:43 ` Thomas Monjalon
2018-03-29 16:50 ` Ferruh Yigit
2018-03-29 17:01 ` Thomas Monjalon
2018-03-29 18:12 ` Hemant Agrawal
2018-03-29 18:28 ` Ferruh Yigit [this message]
2018-03-29 18:21 ` Ferruh Yigit
2018-03-29 18:43 ` Ferruh Yigit
2018-03-30 8:32 ` Thomas Monjalon
2018-03-30 10:15 ` Ferruh Yigit
2018-03-30 11:03 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16136f8e-332f-3b96-21ce-ad05a94c1a54@intel.com \
--to=ferruh.yigit@intel.com \
--cc=dev@dpdk.org \
--cc=hemant.agrawal@nxp.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).