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