Re: [PATCH] mk: fix kernel modules build dependency

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 3/29/2018 7:21 PM, Ferruh Yigit wrote:
> On 3/29/2018 6:01 PM, Thomas Monjalon wrote:
>> 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:
> 
> No, not talking about moving headers to kernel/ folder. But we can "liberate" J
> the kernel modules.
> 
> For KNI, rte_kni_common.h is shared between kernel and userspace, can't escape
> from it. But why this common header needs to depend other dpdk headers at all?
> Indeed commenting out rte_common and rte_config worked fine, it seem there is
> already no dependency.

Hemant is right, putting rte_kni_common makes build dependent to module build,
and module is more fragile.

I agree to move header to userspace library.

> 
> Same thing for igb_uio, why in needs to depend other dpdk headers?
> Following seems fixing the issue, yes it is duplication but I think that is OK:
>  -#include <rte_pci_dev_features.h>
>  +/*#include <rte_pci_dev_features.h>*/
>  +enum rte_intr_mode {
>  +       RTE_INTR_MODE_NONE = 0,
>  +       RTE_INTR_MODE_LEGACY,
>  +       RTE_INTR_MODE_MSI,
>  +       RTE_INTR_MODE_MSIX
>  +};
>  +#define RTE_INTR_MODE_NONE_NAME "none"
>  +#define RTE_INTR_MODE_LEGACY_NAME "legacy"
>  +#define RTE_INTR_MODE_MSI_NAME "msi"
>  +#define RTE_INTR_MODE_MSIX_NAME "msix"
> 
>> 	- rte_pci_dev_features.h
>> 	\- rte_pci_dev_feature_defs.h
>> 	- rte_kni_common.h
>> 	\- rte_common.h
>>
>> Are you sure?
>>
>>
>