[dpdk-dev] [PATCH] mk: fix kernel modules build dependency

[Ferruh Yigit]

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.

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?
> 
>