On Mon, Feb 8, 2021 at 4:22 PM Matteo Croce <mcr...@linux.microsoft.com> wrote: > > On Mon, Feb 8, 2021 at 9:13 PM Bruce Ashfield <bruce.ashfi...@gmail.com> > wrote: > > > > On Mon, Feb 8, 2021 at 1:18 PM Matteo Croce <mcr...@linux.microsoft.com> > > wrote: > > > > > > From: Matteo Croce <mcr...@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
-=-=-=-=-=-=-=-=-=-=-=- 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] -=-=-=-=-=-=-=-=-=-=-=-
