Thread (14 messages) 14 messages, 3 authors, 2018-03-30

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

From: Ferruh Yigit <hidden>
Date: 2018-03-30 10:15:23

On 3/30/2018 9:32 AM, Thomas Monjalon wrote:
29/03/2018 20:43, Ferruh Yigit:
quoted
On 3/29/2018 7:21 PM, Ferruh Yigit wrote:
quoted
On 3/29/2018 6:01 PM, Thomas Monjalon wrote:
quoted
29/03/2018 18:50, Ferruh Yigit:
quoted
On 3/29/2018 5:43 PM, Thomas Monjalon wrote:
quoted
29/03/2018 18:38, Ferruh Yigit:
quoted
On 3/29/2018 5:32 PM, Thomas Monjalon wrote:
quoted
29/03/2018 17:48, Ferruh Yigit:
quoted
On 3/29/2018 4:39 PM, Thomas Monjalon wrote:
quoted
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.
Does it mean you ack this patch?
yep,
Acked-by: Ferruh Yigit <redacted>
Do you want to make a patch to move the header from EAL to librte_kni?

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help