On 1/12/24 11:22, Bruce Ashfield wrote:
On Thu, Jan 11, 2024 at 10:12 PM ChenQi <qi.c...@windriver.com> wrote:
On 1/12/24 10:50, Bruce Ashfield wrote:
On Thu, Jan 11, 2024 at 9:44 PM Chen Qi via lists.openembedded.org
<Qi.Chen=windriver....@lists.openembedded.org> wrote:
From: Chen Qi <qi.c...@windriver.com>
The source files under tools/ also need to be copied because in
some case, they'll be needed. For example, in case that the
CONFIG_DEBUG_INFO_BTF is enabled, we'll get the following error
without this patch when doing 'make prepare'.
No rule to make target '/.../tools/bpf/resolve_btfids/main.o',
needed by '/.../tools/bpf/resolve_btfids/resolve_btfids-in.o'. Stop.
Tools has been excluded on purpose, as it is relatively large
(and complex) compared to the rest of the curated files.
Figure out just what you need for bpf, and copy only those
files.
Bruce
I can do that. However, I want to raise my concern here first. Does the
30M really matter, compared to the potential errors that would possibly
give users bad impression?
Yes, it actually does matter.
That's the entire design principle behind devsrc. It is carefully curated.
Considering something like this pops up every couple of years, I'm
quite confident that there are very few bad impressions to be made.
As you could see from the file that there are many specific copies from
the tools/ directory structure. That should be the hint that if we wanted
to copy tools in its entirety .. we would have done that long ago.
Before enabling CONFIG_DEBUG_INFO_BTF, things were working pretty well
for us. In fact, I was a little surprised that adding extra configs
would result in failure of 'make prepare'.
Not sure if CONFIG_DEBUG_INFO_BTF is the last one. I guess it's probably
not.
Again, if users are using kernel-devsrc for compiling things, do they
really care about the 30M size?
It's not relevant if they do or don't care. It is the principle of keeping it
as minimal as possible and not doing things "just in case".
There's a bugzilla that I've attached a patch that creates a parallel
full source copy of the kernel, but we've never merged it as keeping
to the low footprint design principle is important.
Bruce
Got it. Thanks for the info.
Regards,
Qi
Regards,
Qi
Signed-off-by: Chen Qi <qi.c...@windriver.com>
---
meta/recipes-kernel/linux/kernel-devsrc.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
b/meta/recipes-kernel/linux/kernel-devsrc.bb
index ce5777fbe9..c2aeb8e216 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb
+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
@@ -62,6 +62,7 @@ do_install() {
cd ${S}
cp --parents $(find -type f -name "Makefile*" -o -name "Kconfig*")
$kerneldir/build
cp --parents $(find -type f -name "Build" -o -name "Build.include")
$kerneldir/build
+ cp --parents $(find tools/ -type f -name "*.c" -o -name "*.h")
$kerneldir/build
)
# then drop all but the needed Makefiles/Kconfig files
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193568):
https://lists.openembedded.org/g/openembedded-core/message/193568
Mute This Topic: https://lists.openembedded.org/mt/103676210/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
