* Re: [OE-core] [PATCH] recipes-kernel: add libbpf
2021-02-08 20:13 ` [OE-core] " Bruce Ashfield
@ 2021-02-08 20:24 ` Bruce Ashfield
2021-02-08 21:22 ` Matteo Croce
2021-02-18 2:31 ` Matteo Croce
2 siblings, 0 replies; 11+ messages in thread
From: Bruce Ashfield @ 2021-02-08 20:24 UTC (permalink / raw)
To: Matteo Croce; +Cc: Patches and discussions about the oe-core layer
On Mon, Feb 8, 2021 at 3:13 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>
> On Mon, Feb 8, 2021 at 1:18 PM Matteo Croce <mcroce@linux.microsoft.com> wrote:
> >
> > From: Matteo Croce <mcroce@microsoft.com>
> >
> > 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 <mcroce@microsoft.com>
> > ---
> > ...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 0000000000..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 <mcroce@microsoft.com>
> > +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 <mcroce@microsoft.com>
> > +---
> > + 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 0000000000..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
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [OE-core] [PATCH] recipes-kernel: add libbpf
2021-02-08 20:13 ` [OE-core] " Bruce Ashfield
2021-02-08 20:24 ` Bruce Ashfield
@ 2021-02-08 21:22 ` Matteo Croce
2021-02-08 21:34 ` Bruce Ashfield
2021-02-18 2:31 ` Matteo Croce
2 siblings, 1 reply; 11+ messages in thread
From: Matteo Croce @ 2021-02-08 21:22 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: Patches and discussions about the oe-core layer
On Mon, Feb 8, 2021 at 9:13 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>
> On Mon, Feb 8, 2021 at 1:18 PM Matteo Croce <mcroce@linux.microsoft.com> wrote:
> >
> > From: Matteo Croce <mcroce@microsoft.com>
> >
> > 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] [PATCH] recipes-kernel: add libbpf
2021-02-08 21:22 ` Matteo Croce
@ 2021-02-08 21:34 ` Bruce Ashfield
2021-02-09 16:44 ` Khem Raj
0 siblings, 1 reply; 11+ messages in thread
From: Bruce Ashfield @ 2021-02-08 21:34 UTC (permalink / raw)
To: Matteo Croce; +Cc: Patches and discussions about the oe-core layer
On Mon, Feb 8, 2021 at 4:22 PM Matteo Croce <mcroce@linux.microsoft.com> wrote:
>
> On Mon, Feb 8, 2021 at 9:13 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> >
> > On Mon, Feb 8, 2021 at 1:18 PM Matteo Croce <mcroce@linux.microsoft.com> wrote:
> > >
> > > From: Matteo Croce <mcroce@microsoft.com>
> > >
> > > 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] [PATCH] recipes-kernel: add libbpf
2021-02-08 21:34 ` Bruce Ashfield
@ 2021-02-09 16:44 ` Khem Raj
2021-02-09 17:02 ` Matteo Croce
0 siblings, 1 reply; 11+ messages in thread
From: Khem Raj @ 2021-02-09 16:44 UTC (permalink / raw)
To: Bruce Ashfield
Cc: Matteo Croce, Patches and discussions about the oe-core layer
fails to build for rpi4 here
https://errors.yoctoproject.org/Errors/Details/570276/
On Mon, Feb 8, 2021 at 1:34 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>
> On Mon, Feb 8, 2021 at 4:22 PM Matteo Croce <mcroce@linux.microsoft.com> wrote:
> >
> > On Mon, Feb 8, 2021 at 9:13 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> > >
> > > On Mon, Feb 8, 2021 at 1:18 PM Matteo Croce <mcroce@linux.microsoft.com> wrote:
> > > >
> > > > From: Matteo Croce <mcroce@microsoft.com>
> > > >
> > > > 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
>
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] [PATCH] recipes-kernel: add libbpf
2021-02-09 16:44 ` Khem Raj
@ 2021-02-09 17:02 ` Matteo Croce
0 siblings, 0 replies; 11+ messages in thread
From: Matteo Croce @ 2021-02-09 17:02 UTC (permalink / raw)
To: Khem Raj; +Cc: Bruce Ashfield, Patches and discussions about the oe-core layer
On Tue, Feb 9, 2021 at 5:44 PM Khem Raj <raj.khem@gmail.com> 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 <bruce.ashfield@gmail.com> wrote:
> >
> > On Mon, Feb 8, 2021 at 4:22 PM Matteo Croce <mcroce@linux.microsoft.com> wrote:
> > >
> > > On Mon, Feb 8, 2021 at 9:13 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> > > >
> > > > On Mon, Feb 8, 2021 at 1:18 PM Matteo Croce <mcroce@linux.microsoft.com> wrote:
> > > > >
> > > > > From: Matteo Croce <mcroce@microsoft.com>
> > > > >
> > > > > 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [OE-core] [PATCH] recipes-kernel: add libbpf
2021-02-08 20:13 ` [OE-core] " Bruce Ashfield
2021-02-08 20:24 ` Bruce Ashfield
2021-02-08 21:22 ` Matteo Croce
@ 2021-02-18 2:31 ` Matteo Croce
2021-02-18 3:51 ` Bruce Ashfield
2 siblings, 1 reply; 11+ messages in thread
From: Matteo Croce @ 2021-02-18 2:31 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: Patches and discussions about the oe-core layer
On Mon, Feb 8, 2021 at 9:13 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>
> On Mon, Feb 8, 2021 at 1:18 PM Matteo Croce <mcroce@linux.microsoft.com> wrote:
> >
> > From: Matteo Croce <mcroce@microsoft.com>
> >
> > 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 <mcroce@microsoft.com>
> > ---
> > ...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 0000000000..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 <mcroce@microsoft.com>
> > +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 <mcroce@microsoft.com>
> > +---
> > + 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 0000000000..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
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [OE-core] [PATCH] recipes-kernel: add libbpf
2021-02-18 2:31 ` Matteo Croce
@ 2021-02-18 3:51 ` Bruce Ashfield
2021-02-18 23:04 ` Matteo Croce
0 siblings, 1 reply; 11+ messages in thread
From: Bruce Ashfield @ 2021-02-18 3:51 UTC (permalink / raw)
To: Matteo Croce; +Cc: Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 6603 bytes --]
On Wed, Feb 17, 2021 at 9:32 PM Matteo Croce <mcroce@linux.microsoft.com>
wrote:
> On Mon, Feb 8, 2021 at 9:13 PM Bruce Ashfield <bruce.ashfield@gmail.com>
> wrote:
> >
> > On Mon, Feb 8, 2021 at 1:18 PM Matteo Croce <mcroce@linux.microsoft.com>
> wrote:
> > >
> > > From: Matteo Croce <mcroce@microsoft.com>
> > >
> > > 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 <mcroce@microsoft.com>
> > > ---
> > > ...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 0000000000..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 <mcroce@microsoft.com>
> > > +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) <link to the pull request or
mailing list submission>
That way it is abundantly clear that we aren't carrying it ourselves, and
when we can drop it.
> > > +Signed-off-by: Matteo Croce <mcroce@microsoft.com>
> > > +---
> > > + 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 0000000000..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
>
>
yep. that is doable. oe_runmake will pass them along if in the right
variable.
Bruce
> > 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
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II
[-- Attachment #2: Type: text/html, Size: 10750 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [OE-core] [PATCH] recipes-kernel: add libbpf
2021-02-18 3:51 ` Bruce Ashfield
@ 2021-02-18 23:04 ` Matteo Croce
2021-02-22 16:54 ` Bruce Ashfield
0 siblings, 1 reply; 11+ messages in thread
From: Matteo Croce @ 2021-02-18 23:04 UTC (permalink / raw)
To: Bruce Ashfield, Khem Raj; +Cc: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [OE-core] [PATCH] recipes-kernel: add libbpf
2021-02-18 23:04 ` Matteo Croce
@ 2021-02-22 16:54 ` Bruce Ashfield
0 siblings, 0 replies; 11+ messages in thread
From: Bruce Ashfield @ 2021-02-22 16:54 UTC (permalink / raw)
To: Matteo Croce, Richard Purdie
Cc: Khem Raj, Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 1645 bytes --]
On Thu, Feb 18, 2021 at 6:05 PM Matteo Croce <mcroce@linux.microsoft.com>
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
[-- Attachment #2: Type: text/html, Size: 3057 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread