Re: [OE-core] [PATCH] recipes-kernel: add libbpf
On Thu, Feb 18, 2021 at 6:05 PM Matteo Croce wrote: > Okay, I've addressed all comments but the test one. > > I pushed it to a local fork of meta-oe here: > > https://github.com/teknoraver/meta-openembedded/commit/679944b06ffc564b4b99eae5d934f742bb2a9c09 > > Which kind of test needs to be done here? > A selftest to be run with oe-selftest? A ptest? A tool copied into the > image? > Adding Richard, since he's the one that has the final decision if this gets into oe-core and if the testing is sufficient. I'd suggest looking at the valgrind and the systemtap tests. They are similarly low level tools, with kernel bindings and they both have tests. Something that exercises basic sanity, and runs a few basic tests. I'd expect that the outcome would also be a user of the library in oe-core, which is basically a pre-requisite to get it into core. It doesn't have to be extensive, since it can be extended later. Bruce > If we just need to check if the bpf() syscall is supported, there is > bpftool packaged already, which can list the loaded programs like: > > # bpftool prog > 3: cgroup_device tag 3a32ccd9e03ea87a gpl >loaded_at 2021-02-17T11:50:08+0100 uid 0 >xlated 504B jited 309B memlock 4096B > 4: cgroup_skb tag 6deef7357e7b4530 gpl >loaded_at 2021-02-17T11:50:08+0100 uid 0 >xlated 64B jited 54B memlock 4096B > ... > > Regards, > -- > per aspera ad upstream > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#148483): https://lists.openembedded.org/g/openembedded-core/message/148483 Mute This Topic: https://lists.openembedded.org/mt/80484584/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] recipes-kernel: add libbpf
Okay, I've addressed all comments but the test one. I pushed it to a local fork of meta-oe here: https://github.com/teknoraver/meta-openembedded/commit/679944b06ffc564b4b99eae5d934f742bb2a9c09 Which kind of test needs to be done here? A selftest to be run with oe-selftest? A ptest? A tool copied into the image? If we just need to check if the bpf() syscall is supported, there is bpftool packaged already, which can list the loaded programs like: # bpftool prog 3: cgroup_device tag 3a32ccd9e03ea87a gpl loaded_at 2021-02-17T11:50:08+0100 uid 0 xlated 504B jited 309B memlock 4096B 4: cgroup_skb tag 6deef7357e7b4530 gpl loaded_at 2021-02-17T11:50:08+0100 uid 0 xlated 64B jited 54B memlock 4096B ... Regards, -- per aspera ad upstream -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#148334): https://lists.openembedded.org/g/openembedded-core/message/148334 Mute This Topic: https://lists.openembedded.org/mt/80484584/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] recipes-kernel: add libbpf
On Wed, Feb 17, 2021 at 9:32 PM Matteo Croce wrote: > On Mon, Feb 8, 2021 at 9:13 PM Bruce Ashfield > wrote: > > > > On Mon, Feb 8, 2021 at 1:18 PM Matteo Croce > wrote: > > > > > > From: Matteo Croce > > > > > > Add a recipe to build libbpf from https://github.com/libbpf/libbpf > > > The only patch fixes a build issue, and it's already merged upstream. > > > > Thanks for the submission! I have a few comments / questions. > > > > To get this into oe-core, we should be commenting / documenting why it > > should be in core, versus another layer. The standard criteria is that > > there are enough varied users and that the functionality is common > > enough, that it belongs in core. > > > > There should also be some sort of oe-selftest for the functionality, > > otherwise, it is hard to detect breakages. Some sort of application > > that uses the library and that can be executed in qemu would be > > enough. > > > > What are the kernel requirements ? CONFIG_BPF is selected by other > > kernel configs (it has no menu entry, so it must be), is it that, or > > something else that is the requirement (classic BFP?). If that option > > is now always on, is that true for the reference kernel versions in > > master (5.4 and 5.10). > > > > Something like this will work? I see a similar trick in the uprobe recipe: > > do_compile() { > if grep -q "CONFIG_BPF_SYSCALL=y" ${STAGING_KERNEL_BUILDDIR}/.config > then > oe_runmake > else > bbnote "BFP syscall is not enabled" > fi > } > > Since it already depends on virtual/kernel, that will indeed work. I can't say that I'm a huge fan of checking the .config, since it leaves us open to changing config option names, but that is way less common now than it used to be, so it isn't a problem as a basic sanity check. As you mention, uprobe already sets the prior art on it anyway :D > > > Finally, does this work across all the supported architectures ? if > > not, we'll need compatibility settings. > > > > I'm adding this: > > COMPATIBLE_HOST = "(x86_64.*|i.86.*|aarch64).*-linux" > > That's reasonable. Interested folks can add other architectures if they are willing to help out and support. > > > > > > Signed-off-by: Matteo Croce > > > --- > > > ...01-install-don-t-preserve-file-owner.patch | 29 +++ > > > meta/recipes-kernel/libbpf/libbpf_0.3.bb | 25 > > > 2 files changed, 54 insertions(+) > > > create mode 100644 > meta/recipes-kernel/libbpf/libbpf/0001-install-don-t-preserve-file-owner.patch > > > create mode 100644 meta/recipes-kernel/libbpf/libbpf_0.3.bb > > > > > > diff --git > a/meta/recipes-kernel/libbpf/libbpf/0001-install-don-t-preserve-file-owner.patch > b/meta/recipes-kernel/libbpf/libbpf/0001-install-don-t-preserve-file-owner.patch > > > new file mode 100644 > > > index 00..4e65d8d80a > > > --- /dev/null > > > +++ > b/meta/recipes-kernel/libbpf/libbpf/0001-install-don-t-preserve-file-owner.patch > > > @@ -0,0 +1,29 @@ > > > +From 7df10d91db6f533cc0f6c09f4ae8ad92918c6160 Mon Sep 17 00:00:00 2001 > > > +From: Matteo Croce > > > +Date: Tue, 26 Jan 2021 12:41:47 +0100 > > > +Subject: [PATCH] install: don't preserve file owner > > > + > > > +'cp -p' preserve file ownership, this may leave files owned by the > > > +current in user in /lib . > > > + > > > > We need the upstream status documented here, not just in the commit > message. > > > > You want the upstream commit, or just saying that it will go into 0.4 is > enough? > > We normally do something like: Upstream-status: submitted (0.4 release) That way it is abundantly clear that we aren't carrying it ourselves, and when we can drop it. > > > +Signed-off-by: Matteo Croce > > > +--- > > > + Makefile | 2 +- > > > + 1 file changed, 1 insertion(+), 1 deletion(-) > > > + > > > +diff --git a/Makefile b/Makefile > > > +index da33613..ab66edc 100644 > > > +--- a/Makefile > > > b/Makefile > > > +@@ -130,7 +130,7 @@ define do_s_install > > > + $(Q)if [ ! -d '$(DESTDIR)$2' ]; then\ > > > + $(INSTALL) -d -m 755 '$(DESTDIR)$2';\ > > > + fi; > > > +- $(Q)cp -fpR $1 '$(DESTDIR)$2' > > > ++ $(Q)cp -fR $1 '$(DESTDIR)$2' > > > + endef > > > + > > > + install: all install_headers install_pkgconfig > > > +-- > > > +2.29.2 > > > + > > > diff --git a/meta/recipes-kernel/libbpf/libbpf_0.3.bb > b/meta/recipes-kernel/libbpf/libbpf_0.3.bb > > > new file mode 100644 > > > index 00..402e57257f > > > --- /dev/null > > > +++ b/meta/recipes-kernel/libbpf/libbpf_0.3.bb > > > @@ -0,0 +1,25 @@ > > > +SUMMARY = "Library for BPF handling" > > > +DESCRIPTION = "Library for BPF handling" > > > +HOMEPAGE = "https://github.com/libbpf/libbpf; > > > +SECTION = "libs" > > > +LICENSE = "LGPLv2.1+" > > > + > > > +LIC_FILES_CHKSUM = > "file://../LICENSE.LPGL-2.1;md5=b370887980db5dd40659b50909238dbd" > > > + > > > +DEPENDS = "zlib elfutils" > > > + > > > +SRC_URI = "git://github.com/libbpf/libbpf.git;protocol=https" > > > +SRCREV
Re: [OE-core] [PATCH] recipes-kernel: add libbpf
On Mon, Feb 8, 2021 at 9:13 PM Bruce Ashfield wrote: > > On Mon, Feb 8, 2021 at 1:18 PM Matteo Croce > wrote: > > > > From: Matteo Croce > > > > Add a recipe to build libbpf from https://github.com/libbpf/libbpf > > The only patch fixes a build issue, and it's already merged upstream. > > Thanks for the submission! I have a few comments / questions. > > To get this into oe-core, we should be commenting / documenting why it > should be in core, versus another layer. The standard criteria is that > there are enough varied users and that the functionality is common > enough, that it belongs in core. > > There should also be some sort of oe-selftest for the functionality, > otherwise, it is hard to detect breakages. Some sort of application > that uses the library and that can be executed in qemu would be > enough. > > What are the kernel requirements ? CONFIG_BPF is selected by other > kernel configs (it has no menu entry, so it must be), is it that, or > something else that is the requirement (classic BFP?). If that option > is now always on, is that true for the reference kernel versions in > master (5.4 and 5.10). > Something like this will work? I see a similar trick in the uprobe recipe: do_compile() { if grep -q "CONFIG_BPF_SYSCALL=y" ${STAGING_KERNEL_BUILDDIR}/.config then oe_runmake else bbnote "BFP syscall is not enabled" fi } > Finally, does this work across all the supported architectures ? if > not, we'll need compatibility settings. > I'm adding this: COMPATIBLE_HOST = "(x86_64.*|i.86.*|aarch64).*-linux" > > > > Signed-off-by: Matteo Croce > > --- > > ...01-install-don-t-preserve-file-owner.patch | 29 +++ > > meta/recipes-kernel/libbpf/libbpf_0.3.bb | 25 > > 2 files changed, 54 insertions(+) > > create mode 100644 > > meta/recipes-kernel/libbpf/libbpf/0001-install-don-t-preserve-file-owner.patch > > create mode 100644 meta/recipes-kernel/libbpf/libbpf_0.3.bb > > > > diff --git > > a/meta/recipes-kernel/libbpf/libbpf/0001-install-don-t-preserve-file-owner.patch > > > > b/meta/recipes-kernel/libbpf/libbpf/0001-install-don-t-preserve-file-owner.patch > > new file mode 100644 > > index 00..4e65d8d80a > > --- /dev/null > > +++ > > b/meta/recipes-kernel/libbpf/libbpf/0001-install-don-t-preserve-file-owner.patch > > @@ -0,0 +1,29 @@ > > +From 7df10d91db6f533cc0f6c09f4ae8ad92918c6160 Mon Sep 17 00:00:00 2001 > > +From: Matteo Croce > > +Date: Tue, 26 Jan 2021 12:41:47 +0100 > > +Subject: [PATCH] install: don't preserve file owner > > + > > +'cp -p' preserve file ownership, this may leave files owned by the > > +current in user in /lib . > > + > > We need the upstream status documented here, not just in the commit message. > You want the upstream commit, or just saying that it will go into 0.4 is enough? > > +Signed-off-by: Matteo Croce > > +--- > > + Makefile | 2 +- > > + 1 file changed, 1 insertion(+), 1 deletion(-) > > + > > +diff --git a/Makefile b/Makefile > > +index da33613..ab66edc 100644 > > +--- a/Makefile > > b/Makefile > > +@@ -130,7 +130,7 @@ define do_s_install > > + $(Q)if [ ! -d '$(DESTDIR)$2' ]; then\ > > + $(INSTALL) -d -m 755 '$(DESTDIR)$2';\ > > + fi; > > +- $(Q)cp -fpR $1 '$(DESTDIR)$2' > > ++ $(Q)cp -fR $1 '$(DESTDIR)$2' > > + endef > > + > > + install: all install_headers install_pkgconfig > > +-- > > +2.29.2 > > + > > diff --git a/meta/recipes-kernel/libbpf/libbpf_0.3.bb > > b/meta/recipes-kernel/libbpf/libbpf_0.3.bb > > new file mode 100644 > > index 00..402e57257f > > --- /dev/null > > +++ b/meta/recipes-kernel/libbpf/libbpf_0.3.bb > > @@ -0,0 +1,25 @@ > > +SUMMARY = "Library for BPF handling" > > +DESCRIPTION = "Library for BPF handling" > > +HOMEPAGE = "https://github.com/libbpf/libbpf; > > +SECTION = "libs" > > +LICENSE = "LGPLv2.1+" > > + > > +LIC_FILES_CHKSUM = > > "file://../LICENSE.LPGL-2.1;md5=b370887980db5dd40659b50909238dbd" > > + > > +DEPENDS = "zlib elfutils" > > + > > +SRC_URI = "git://github.com/libbpf/libbpf.git;protocol=https" > > +SRCREV = "051a4009f94d5633a8f734ca4235f0a78ee90469" > > + > > +# Backported from version 0.4 > > +SRC_URI += "file://0001-install-don-t-preserve-file-owner.patch" > > + > > +S = "${WORKDIR}/git/src" > > + > > +inherit pkgconfig > > I see inherit pkgconfig, but no PACKAGECONFIG setting. Is it actually > used here ? > > > + > > +do_install() { > > + make install DESTDIR=${D} LIBDIR=${libdir} > > Rather than a bare 'make' call, this should likely be oe_runmake > Right. While at it, what about adding DESTDIR and LIBDIR to ${EXTRA_OEMAKE}? They are ignored in the build phase > Bruce > > > +} > > + > > +BBCLASSEXTEND = "native" > > -- > > 2.29.2 > > > > > > > > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II Regards, -- per aspera ad upstream -=-=-=-=-=-=-=-=-=-=-=- Links: You receive
Re: [OE-core] [PATCH] recipes-kernel: add libbpf
On Tue, Feb 9, 2021 at 5:44 PM Khem Raj wrote: > > fails to build for rpi4 here > > https://errors.yoctoproject.org/Errors/Details/570276/ > > On Mon, Feb 8, 2021 at 1:34 PM Bruce Ashfield > wrote: > > > > On Mon, Feb 8, 2021 at 4:22 PM Matteo Croce > > wrote: > > > > > > On Mon, Feb 8, 2021 at 9:13 PM Bruce Ashfield > > > wrote: > > > > > > > > On Mon, Feb 8, 2021 at 1:18 PM Matteo Croce > > > > wrote: > > > > > > > > > > From: Matteo Croce > > > > > > > > > > Add a recipe to build libbpf from https://github.com/libbpf/libbpf > > > > > The only patch fixes a build issue, and it's already merged upstream. > > > > > > > > Thanks for the submission! I have a few comments / questions. > > > > > > > > To get this into oe-core, we should be commenting / documenting why it > > > > should be in core, versus another layer. The standard criteria is that > > > > there are enough varied users and that the functionality is common > > > > enough, that it belongs in core. > > > > > > > > > > For sure bcc and bpftrace can use it, and maybe also perf. > > > In future even iproute2 will use it, as it has been ported to libbpf > > > recently. > > > Feel free to propose another layer, in case you know a better one. > > > > That's not for me to propose . that's for you to sort out. > > > > A quick check of the layer index would show that other bpf tools are > > in meta-oe. > > > > > > > > > > > > There should also be some sort of oe-selftest for the functionality, > > > > otherwise, it is hard to detect breakages. Some sort of application > > > > that uses the library and that can be executed in qemu would be > > > > enough. > > > > > > > > > > That's doable. > > > > > > > What are the kernel requirements ? CONFIG_BPF is selected by other > > > > kernel configs (it has no menu entry, so it must be), is it that, or > > > > something else that is the requirement (classic BFP?). If that option > > > > is now always on, is that true for the reference kernel versions in > > > > master (5.4 and 5.10). > > > > > > > > > > I'd say BPF_SYSCALL, which is the single entry point for al the eBPF > > > routines. > > > > Yes, that's the core support, and a selftest would ensure that the > > reference kernels can support the package (they can, but we still need > > the test) and implicitly document that requirement. > > > > > > > > > Finally, does this work across all the supported architectures ? if > > > > not, we'll need compatibility settings. > > > > > > > > > > I tested it only x86 and aarch64, but it should be arch independent. > > > > Then it should be limited to where it has been tested, otherwise, the > > burden falls to the oe-core maintainer, which we don't want. > > > > Bruce > > > > > > > > Thanks! > > > -- > > > per aspera ad upstream > > > > > > > > -- > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > thee at its end > > - "Use the force Harry" - Gandalf, Star Trek II > > > > > > Hi, to let bcc use the libbpf dynamic library, you need to backport some commits from upstream: This one which I recently pushed: https://github.com/iovisor/bcc/commit/6b4222cd41b3f5e833307aeff2b10c6b084d3f4f And these from Luca: https://github.com/iovisor/bcc/commit/e46997e9a43d512b6a5d01aae1a4566fd147b7b9 https://github.com/iovisor/bcc/commit/300296a598613912df5dc61f4b327b7102e52011 https://github.com/iovisor/bcc/commit/1cb5026e6f1d8dc7ca115cae579be4c53bec0c9e And you need to pass to cmake some extra flags. I have both bcc and bpftraf working with dynamic libbpf, I will share my changes to the bcc recipes once libbpf is merged. Regards, -- per aspera ad upstream -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147909): https://lists.openembedded.org/g/openembedded-core/message/147909 Mute This Topic: https://lists.openembedded.org/mt/80484584/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] recipes-kernel: add libbpf
fails to build for rpi4 here https://errors.yoctoproject.org/Errors/Details/570276/ On Mon, Feb 8, 2021 at 1:34 PM Bruce Ashfield wrote: > > On Mon, Feb 8, 2021 at 4:22 PM Matteo Croce > wrote: > > > > On Mon, Feb 8, 2021 at 9:13 PM Bruce Ashfield > > wrote: > > > > > > On Mon, Feb 8, 2021 at 1:18 PM Matteo Croce > > > wrote: > > > > > > > > From: Matteo Croce > > > > > > > > Add a recipe to build libbpf from https://github.com/libbpf/libbpf > > > > The only patch fixes a build issue, and it's already merged upstream. > > > > > > Thanks for the submission! I have a few comments / questions. > > > > > > To get this into oe-core, we should be commenting / documenting why it > > > should be in core, versus another layer. The standard criteria is that > > > there are enough varied users and that the functionality is common > > > enough, that it belongs in core. > > > > > > > For sure bcc and bpftrace can use it, and maybe also perf. > > In future even iproute2 will use it, as it has been ported to libbpf > > recently. > > Feel free to propose another layer, in case you know a better one. > > That's not for me to propose . that's for you to sort out. > > A quick check of the layer index would show that other bpf tools are > in meta-oe. > > > > > > > > There should also be some sort of oe-selftest for the functionality, > > > otherwise, it is hard to detect breakages. Some sort of application > > > that uses the library and that can be executed in qemu would be > > > enough. > > > > > > > That's doable. > > > > > What are the kernel requirements ? CONFIG_BPF is selected by other > > > kernel configs (it has no menu entry, so it must be), is it that, or > > > something else that is the requirement (classic BFP?). If that option > > > is now always on, is that true for the reference kernel versions in > > > master (5.4 and 5.10). > > > > > > > I'd say BPF_SYSCALL, which is the single entry point for al the eBPF > > routines. > > Yes, that's the core support, and a selftest would ensure that the > reference kernels can support the package (they can, but we still need > the test) and implicitly document that requirement. > > > > > > Finally, does this work across all the supported architectures ? if > > > not, we'll need compatibility settings. > > > > > > > I tested it only x86 and aarch64, but it should be arch independent. > > Then it should be limited to where it has been tested, otherwise, the > burden falls to the oe-core maintainer, which we don't want. > > Bruce > > > > > Thanks! > > -- > > per aspera ad upstream > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147906): https://lists.openembedded.org/g/openembedded-core/message/147906 Mute This Topic: https://lists.openembedded.org/mt/80484584/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] recipes-kernel: add libbpf
On Mon, Feb 8, 2021 at 4:22 PM Matteo Croce wrote: > > On Mon, Feb 8, 2021 at 9:13 PM Bruce Ashfield > wrote: > > > > On Mon, Feb 8, 2021 at 1:18 PM Matteo Croce > > wrote: > > > > > > From: Matteo Croce > > > > > > Add a recipe to build libbpf from https://github.com/libbpf/libbpf > > > The only patch fixes a build issue, and it's already merged upstream. > > > > Thanks for the submission! I have a few comments / questions. > > > > To get this into oe-core, we should be commenting / documenting why it > > should be in core, versus another layer. The standard criteria is that > > there are enough varied users and that the functionality is common > > enough, that it belongs in core. > > > > For sure bcc and bpftrace can use it, and maybe also perf. > In future even iproute2 will use it, as it has been ported to libbpf recently. > Feel free to propose another layer, in case you know a better one. That's not for me to propose . that's for you to sort out. A quick check of the layer index would show that other bpf tools are in meta-oe. > > > > There should also be some sort of oe-selftest for the functionality, > > otherwise, it is hard to detect breakages. Some sort of application > > that uses the library and that can be executed in qemu would be > > enough. > > > > That's doable. > > > What are the kernel requirements ? CONFIG_BPF is selected by other > > kernel configs (it has no menu entry, so it must be), is it that, or > > something else that is the requirement (classic BFP?). If that option > > is now always on, is that true for the reference kernel versions in > > master (5.4 and 5.10). > > > > I'd say BPF_SYSCALL, which is the single entry point for al the eBPF routines. Yes, that's the core support, and a selftest would ensure that the reference kernels can support the package (they can, but we still need the test) and implicitly document that requirement. > > > Finally, does this work across all the supported architectures ? if > > not, we'll need compatibility settings. > > > > I tested it only x86 and aarch64, but it should be arch independent. Then it should be limited to where it has been tested, otherwise, the burden falls to the oe-core maintainer, which we don't want. Bruce > > Thanks! > -- > per aspera ad upstream -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147842): https://lists.openembedded.org/g/openembedded-core/message/147842 Mute This Topic: https://lists.openembedded.org/mt/80484584/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] recipes-kernel: add libbpf
On Mon, Feb 8, 2021 at 9:13 PM Bruce Ashfield wrote: > > On Mon, Feb 8, 2021 at 1:18 PM Matteo Croce > wrote: > > > > From: Matteo Croce > > > > Add a recipe to build libbpf from https://github.com/libbpf/libbpf > > The only patch fixes a build issue, and it's already merged upstream. > > Thanks for the submission! I have a few comments / questions. > > To get this into oe-core, we should be commenting / documenting why it > should be in core, versus another layer. The standard criteria is that > there are enough varied users and that the functionality is common > enough, that it belongs in core. > For sure bcc and bpftrace can use it, and maybe also perf. In future even iproute2 will use it, as it has been ported to libbpf recently. Feel free to propose another layer, in case you know a better one. > There should also be some sort of oe-selftest for the functionality, > otherwise, it is hard to detect breakages. Some sort of application > that uses the library and that can be executed in qemu would be > enough. > That's doable. > What are the kernel requirements ? CONFIG_BPF is selected by other > kernel configs (it has no menu entry, so it must be), is it that, or > something else that is the requirement (classic BFP?). If that option > is now always on, is that true for the reference kernel versions in > master (5.4 and 5.10). > I'd say BPF_SYSCALL, which is the single entry point for al the eBPF routines. > Finally, does this work across all the supported architectures ? if > not, we'll need compatibility settings. > I tested it only x86 and aarch64, but it should be arch independent. Thanks! -- per aspera ad upstream -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147841): https://lists.openembedded.org/g/openembedded-core/message/147841 Mute This Topic: https://lists.openembedded.org/mt/80484584/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] recipes-kernel: add libbpf
On Mon, Feb 8, 2021 at 3:13 PM Bruce Ashfield wrote: > > On Mon, Feb 8, 2021 at 1:18 PM Matteo Croce > wrote: > > > > From: Matteo Croce > > > > Add a recipe to build libbpf from https://github.com/libbpf/libbpf > > The only patch fixes a build issue, and it's already merged upstream. > > Thanks for the submission! I have a few comments / questions. > > To get this into oe-core, we should be commenting / documenting why it > should be in core, versus another layer. The standard criteria is that > there are enough varied users and that the functionality is common > enough, that it belongs in core. One more thing. If added to core, it would also need an entry in the 'maintainers.inc' file. Cheers, Bruce > > There should also be some sort of oe-selftest for the functionality, > otherwise, it is hard to detect breakages. Some sort of application > that uses the library and that can be executed in qemu would be > enough. > > What are the kernel requirements ? CONFIG_BPF is selected by other > kernel configs (it has no menu entry, so it must be), is it that, or > something else that is the requirement (classic BFP?). If that option > is now always on, is that true for the reference kernel versions in > master (5.4 and 5.10). > > Finally, does this work across all the supported architectures ? if > not, we'll need compatibility settings. > > > > > Signed-off-by: Matteo Croce > > --- > > ...01-install-don-t-preserve-file-owner.patch | 29 +++ > > meta/recipes-kernel/libbpf/libbpf_0.3.bb | 25 > > 2 files changed, 54 insertions(+) > > create mode 100644 > > meta/recipes-kernel/libbpf/libbpf/0001-install-don-t-preserve-file-owner.patch > > create mode 100644 meta/recipes-kernel/libbpf/libbpf_0.3.bb > > > > diff --git > > a/meta/recipes-kernel/libbpf/libbpf/0001-install-don-t-preserve-file-owner.patch > > > > b/meta/recipes-kernel/libbpf/libbpf/0001-install-don-t-preserve-file-owner.patch > > new file mode 100644 > > index 00..4e65d8d80a > > --- /dev/null > > +++ > > b/meta/recipes-kernel/libbpf/libbpf/0001-install-don-t-preserve-file-owner.patch > > @@ -0,0 +1,29 @@ > > +From 7df10d91db6f533cc0f6c09f4ae8ad92918c6160 Mon Sep 17 00:00:00 2001 > > +From: Matteo Croce > > +Date: Tue, 26 Jan 2021 12:41:47 +0100 > > +Subject: [PATCH] install: don't preserve file owner > > + > > +'cp -p' preserve file ownership, this may leave files owned by the > > +current in user in /lib . > > + > > We need the upstream status documented here, not just in the commit message. > > > +Signed-off-by: Matteo Croce > > +--- > > + Makefile | 2 +- > > + 1 file changed, 1 insertion(+), 1 deletion(-) > > + > > +diff --git a/Makefile b/Makefile > > +index da33613..ab66edc 100644 > > +--- a/Makefile > > b/Makefile > > +@@ -130,7 +130,7 @@ define do_s_install > > + $(Q)if [ ! -d '$(DESTDIR)$2' ]; then\ > > + $(INSTALL) -d -m 755 '$(DESTDIR)$2';\ > > + fi; > > +- $(Q)cp -fpR $1 '$(DESTDIR)$2' > > ++ $(Q)cp -fR $1 '$(DESTDIR)$2' > > + endef > > + > > + install: all install_headers install_pkgconfig > > +-- > > +2.29.2 > > + > > diff --git a/meta/recipes-kernel/libbpf/libbpf_0.3.bb > > b/meta/recipes-kernel/libbpf/libbpf_0.3.bb > > new file mode 100644 > > index 00..402e57257f > > --- /dev/null > > +++ b/meta/recipes-kernel/libbpf/libbpf_0.3.bb > > @@ -0,0 +1,25 @@ > > +SUMMARY = "Library for BPF handling" > > +DESCRIPTION = "Library for BPF handling" > > +HOMEPAGE = "https://github.com/libbpf/libbpf; > > +SECTION = "libs" > > +LICENSE = "LGPLv2.1+" > > + > > +LIC_FILES_CHKSUM = > > "file://../LICENSE.LPGL-2.1;md5=b370887980db5dd40659b50909238dbd" > > + > > +DEPENDS = "zlib elfutils" > > + > > +SRC_URI = "git://github.com/libbpf/libbpf.git;protocol=https" > > +SRCREV = "051a4009f94d5633a8f734ca4235f0a78ee90469" > > + > > +# Backported from version 0.4 > > +SRC_URI += "file://0001-install-don-t-preserve-file-owner.patch" > > + > > +S = "${WORKDIR}/git/src" > > + > > +inherit pkgconfig > > I see inherit pkgconfig, but no PACKAGECONFIG setting. Is it actually > used here ? > > > + > > +do_install() { > > + make install DESTDIR=${D} LIBDIR=${libdir} > > Rather than a bare 'make' call, this should likely be oe_runmake > > Bruce > > > +} > > + > > +BBCLASSEXTEND = "native" > > -- > > 2.29.2 > > > > > > > > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147840): https://lists.openembedded.org/g/openembedded-core/message/147840 Mute This Topic: https://lists.openembedded.org/mt/80484584/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe:
Re: [OE-core] [PATCH] recipes-kernel: add libbpf
On Mon, Feb 8, 2021 at 1:18 PM Matteo Croce wrote: > > From: Matteo Croce > > Add a recipe to build libbpf from https://github.com/libbpf/libbpf > The only patch fixes a build issue, and it's already merged upstream. Thanks for the submission! I have a few comments / questions. To get this into oe-core, we should be commenting / documenting why it should be in core, versus another layer. The standard criteria is that there are enough varied users and that the functionality is common enough, that it belongs in core. There should also be some sort of oe-selftest for the functionality, otherwise, it is hard to detect breakages. Some sort of application that uses the library and that can be executed in qemu would be enough. What are the kernel requirements ? CONFIG_BPF is selected by other kernel configs (it has no menu entry, so it must be), is it that, or something else that is the requirement (classic BFP?). If that option is now always on, is that true for the reference kernel versions in master (5.4 and 5.10). Finally, does this work across all the supported architectures ? if not, we'll need compatibility settings. > > Signed-off-by: Matteo Croce > --- > ...01-install-don-t-preserve-file-owner.patch | 29 +++ > meta/recipes-kernel/libbpf/libbpf_0.3.bb | 25 > 2 files changed, 54 insertions(+) > create mode 100644 > meta/recipes-kernel/libbpf/libbpf/0001-install-don-t-preserve-file-owner.patch > create mode 100644 meta/recipes-kernel/libbpf/libbpf_0.3.bb > > diff --git > a/meta/recipes-kernel/libbpf/libbpf/0001-install-don-t-preserve-file-owner.patch > > b/meta/recipes-kernel/libbpf/libbpf/0001-install-don-t-preserve-file-owner.patch > new file mode 100644 > index 00..4e65d8d80a > --- /dev/null > +++ > b/meta/recipes-kernel/libbpf/libbpf/0001-install-don-t-preserve-file-owner.patch > @@ -0,0 +1,29 @@ > +From 7df10d91db6f533cc0f6c09f4ae8ad92918c6160 Mon Sep 17 00:00:00 2001 > +From: Matteo Croce > +Date: Tue, 26 Jan 2021 12:41:47 +0100 > +Subject: [PATCH] install: don't preserve file owner > + > +'cp -p' preserve file ownership, this may leave files owned by the > +current in user in /lib . > + We need the upstream status documented here, not just in the commit message. > +Signed-off-by: Matteo Croce > +--- > + Makefile | 2 +- > + 1 file changed, 1 insertion(+), 1 deletion(-) > + > +diff --git a/Makefile b/Makefile > +index da33613..ab66edc 100644 > +--- a/Makefile > b/Makefile > +@@ -130,7 +130,7 @@ define do_s_install > + $(Q)if [ ! -d '$(DESTDIR)$2' ]; then\ > + $(INSTALL) -d -m 755 '$(DESTDIR)$2';\ > + fi; > +- $(Q)cp -fpR $1 '$(DESTDIR)$2' > ++ $(Q)cp -fR $1 '$(DESTDIR)$2' > + endef > + > + install: all install_headers install_pkgconfig > +-- > +2.29.2 > + > diff --git a/meta/recipes-kernel/libbpf/libbpf_0.3.bb > b/meta/recipes-kernel/libbpf/libbpf_0.3.bb > new file mode 100644 > index 00..402e57257f > --- /dev/null > +++ b/meta/recipes-kernel/libbpf/libbpf_0.3.bb > @@ -0,0 +1,25 @@ > +SUMMARY = "Library for BPF handling" > +DESCRIPTION = "Library for BPF handling" > +HOMEPAGE = "https://github.com/libbpf/libbpf; > +SECTION = "libs" > +LICENSE = "LGPLv2.1+" > + > +LIC_FILES_CHKSUM = > "file://../LICENSE.LPGL-2.1;md5=b370887980db5dd40659b50909238dbd" > + > +DEPENDS = "zlib elfutils" > + > +SRC_URI = "git://github.com/libbpf/libbpf.git;protocol=https" > +SRCREV = "051a4009f94d5633a8f734ca4235f0a78ee90469" > + > +# Backported from version 0.4 > +SRC_URI += "file://0001-install-don-t-preserve-file-owner.patch" > + > +S = "${WORKDIR}/git/src" > + > +inherit pkgconfig I see inherit pkgconfig, but no PACKAGECONFIG setting. Is it actually used here ? > + > +do_install() { > + make install DESTDIR=${D} LIBDIR=${libdir} Rather than a bare 'make' call, this should likely be oe_runmake Bruce > +} > + > +BBCLASSEXTEND = "native" > -- > 2.29.2 > > > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147839): https://lists.openembedded.org/g/openembedded-core/message/147839 Mute This Topic: https://lists.openembedded.org/mt/80484584/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] recipes-kernel: add libbpf
From: Matteo Croce Add a recipe to build libbpf from https://github.com/libbpf/libbpf The only patch fixes a build issue, and it's already merged upstream. Signed-off-by: Matteo Croce --- ...01-install-don-t-preserve-file-owner.patch | 29 +++ meta/recipes-kernel/libbpf/libbpf_0.3.bb | 25 2 files changed, 54 insertions(+) create mode 100644 meta/recipes-kernel/libbpf/libbpf/0001-install-don-t-preserve-file-owner.patch create mode 100644 meta/recipes-kernel/libbpf/libbpf_0.3.bb diff --git a/meta/recipes-kernel/libbpf/libbpf/0001-install-don-t-preserve-file-owner.patch b/meta/recipes-kernel/libbpf/libbpf/0001-install-don-t-preserve-file-owner.patch new file mode 100644 index 00..4e65d8d80a --- /dev/null +++ b/meta/recipes-kernel/libbpf/libbpf/0001-install-don-t-preserve-file-owner.patch @@ -0,0 +1,29 @@ +From 7df10d91db6f533cc0f6c09f4ae8ad92918c6160 Mon Sep 17 00:00:00 2001 +From: Matteo Croce +Date: Tue, 26 Jan 2021 12:41:47 +0100 +Subject: [PATCH] install: don't preserve file owner + +'cp -p' preserve file ownership, this may leave files owned by the +current in user in /lib . + +Signed-off-by: Matteo Croce +--- + Makefile | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/Makefile b/Makefile +index da33613..ab66edc 100644 +--- a/Makefile b/Makefile +@@ -130,7 +130,7 @@ define do_s_install + $(Q)if [ ! -d '$(DESTDIR)$2' ]; then\ + $(INSTALL) -d -m 755 '$(DESTDIR)$2';\ + fi; +- $(Q)cp -fpR $1 '$(DESTDIR)$2' ++ $(Q)cp -fR $1 '$(DESTDIR)$2' + endef + + install: all install_headers install_pkgconfig +-- +2.29.2 + diff --git a/meta/recipes-kernel/libbpf/libbpf_0.3.bb b/meta/recipes-kernel/libbpf/libbpf_0.3.bb new file mode 100644 index 00..402e57257f --- /dev/null +++ b/meta/recipes-kernel/libbpf/libbpf_0.3.bb @@ -0,0 +1,25 @@ +SUMMARY = "Library for BPF handling" +DESCRIPTION = "Library for BPF handling" +HOMEPAGE = "https://github.com/libbpf/libbpf; +SECTION = "libs" +LICENSE = "LGPLv2.1+" + +LIC_FILES_CHKSUM = "file://../LICENSE.LPGL-2.1;md5=b370887980db5dd40659b50909238dbd" + +DEPENDS = "zlib elfutils" + +SRC_URI = "git://github.com/libbpf/libbpf.git;protocol=https" +SRCREV = "051a4009f94d5633a8f734ca4235f0a78ee90469" + +# Backported from version 0.4 +SRC_URI += "file://0001-install-don-t-preserve-file-owner.patch" + +S = "${WORKDIR}/git/src" + +inherit pkgconfig + +do_install() { + make install DESTDIR=${D} LIBDIR=${libdir} +} + +BBCLASSEXTEND = "native" -- 2.29.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147834): https://lists.openembedded.org/g/openembedded-core/message/147834 Mute This Topic: https://lists.openembedded.org/mt/80484584/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-