[Buildroot] [PATCH 0/4] package/kmemd: new package

[Buildroot] [PATCH 0/4] package/kmemd: new package

[Tobias Waldekranz]

kmemd implements a GDB stub that let's you access a running kernel's
memory. There's no way to control the flow of execution in any way,
but you can inspect internal data structures with all the DWARF
parsing and scripting power of GDB - without the need for any hardware
debugger or a dedicated KGDB serial port.

I've chosen not to install any startup scripts for it, since it
effectively provides the same service as Heartbleed, but with a much
better UX :) The expectation is that the user will start it manually
when needed.

Before adding kmemd, 1-3/4 fixes some issues around libbpf. The
cross-compilation fix for 32-bit targets (1/4) has been accepted
upstream[1].

[1]: https://github.com/libbpf/libbpf/commit/68e6f83f223ebf3fbf0d94c0f4592e5e6773f0c1

Tobias Waldekranz (4):
  package/libbpf: fix cross compilation for 32-bit targets
  package/libbpf: remove architecture restrictions
  package/libbpf: extract dependencies to separate kconfig symbol
  package/kmemd: new package

 package/Config.in                             |  1 +
 package/kmemd/Config.in                       | 11 ++++++
 package/kmemd/kmemd.hash                      |  5 +++
 package/kmemd/kmemd.mk                        | 20 ++++++++++
 ...cross-compilation-for-32-bit-targets.patch | 37 +++++++++++++++++++
 package/libbpf/Config.in                      | 24 ++++--------
 6 files changed, 81 insertions(+), 17 deletions(-)
 create mode 100644 package/kmemd/Config.in
 create mode 100644 package/kmemd/kmemd.hash
 create mode 100644 package/kmemd/kmemd.mk
 create mode 100644 package/libbpf/1.0.1/0001-Makefile-Fix-cross-compilation-for-32-bit-targets.patch

-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 1/4] package/libbpf: fix cross compilation for 32-bit targets

[Tobias Waldekranz]

Add upstream patch that sources the library path (lib vs. lib64) from
the compiler rather than from uname(1).

Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
---
 ...cross-compilation-for-32-bit-targets.patch | 37 +++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 package/libbpf/1.0.1/0001-Makefile-Fix-cross-compilation-for-32-bit-targets.patch

diff --git a/package/libbpf/1.0.1/0001-Makefile-Fix-cross-compilation-for-32-bit-targets.patch b/package/libbpf/1.0.1/0001-Makefile-Fix-cross-compilation-for-32-bit-targets.patch
new file mode 100644
index 0000000000..3730b2fa41
--- /dev/null
+++ b/package/libbpf/1.0.1/0001-Makefile-Fix-cross-compilation-for-32-bit-targets.patch
@@ -0,0 +1,37 @@
+From 68e6f83f223ebf3fbf0d94c0f4592e5e6773f0c1 Mon Sep 17 00:00:00 2001
+From: Tobias Waldekranz <tobias@waldekranz.com>
+Date: Fri, 14 Oct 2022 21:14:14 +0200
+Subject: [PATCH] Makefile: Fix cross-compilation for 32-bit targets
+
+Determining the correct library installation path (lib vs. lib64)
+using uname(1) breaks in cross compilation scenarios where word widths
+differ between the host and target system.
+
+Instead, source the information from the compilers '-dumpmachine'
+option (supported by both GCC and Clang).
+
+We call this the "host" architecture, using the same nomenclature as
+Autotools (--host configure option).
+
+Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
+---
+ src/Makefile | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/src/Makefile b/src/Makefile
+index 3cd0854..d535f81 100644
+--- a/src/Makefile
++++ b/src/Makefile
+@@ -77,7 +77,8 @@ INSTALL = install
+ 
+ DESTDIR ?=
+ 
+-ifeq ($(filter-out %64 %64be %64eb %64le %64el s390x, $(shell uname -m)),)
++HOSTARCH = $(firstword $(subst -, ,$(shell $(CC) -dumpmachine)))
++ifeq ($(filter-out %64 %64be %64eb %64le %64el s390x, $(HOSTARCH)),)
+ 	LIBSUBDIR := lib64
+ else
+ 	LIBSUBDIR := lib
+-- 
+2.34.1
+
-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4] package/libbpf: fix cross compilation for 32-bit targets

[Thomas Petazzoni via buildroot]

Hello Tobias,

Thanks for this patch!

On Thu, 20 Oct 2022 16:14:09 +0200
Tobias Waldekranz <tobias@waldekranz.com> wrote:

> Add upstream patch that sources the library path (lib vs. lib64) from
> the compiler rather than from uname(1).

Could you copy/paste the details of the build failure that was
occurring, and provide details on the context it was occurring?

Indeed, when looking at the results of our autobuilders in terms of
failures when building libbpf, I don't see anything relevant:

  http://autobuild.buildroot.net/?reason=libbpf%

In recent months, we only had build failures on the S390x architecture,
that don't seem related to this.

>  ...cross-compilation-for-32-bit-targets.patch | 37 +++++++++++++++++++
>  1 file changed, 37 insertions(+)
>  create mode 100644 package/libbpf/1.0.1/0001-Makefile-Fix-cross-compilation-for-32-bit-targets.patch
> 
> diff --git a/package/libbpf/1.0.1/0001-Makefile-Fix-cross-compilation-for-32-bit-targets.patch b/package/libbpf/1.0.1/0001-Makefile-Fix-cross-compilation-for-32-bit-targets.patch
> new file mode 100644
> index 0000000000..3730b2fa41

Please put the patch directly in package/libbpf/. Putting it in a
1.0.1/ sub-directory is not needed. We only do that for packages where
multiple versions are used (like package/gcc, package/binutils for
example).

> --- /dev/null
> +++ b/package/libbpf/1.0.1/0001-Makefile-Fix-cross-compilation-for-32-bit-targets.patch
> @@ -0,0 +1,37 @@
> +From 68e6f83f223ebf3fbf0d94c0f4592e5e6773f0c1 Mon Sep 17 00:00:00 2001
> +From: Tobias Waldekranz <tobias@waldekranz.com>
> +Date: Fri, 14 Oct 2022 21:14:14 +0200
> +Subject: [PATCH] Makefile: Fix cross-compilation for 32-bit targets
> +
> +Determining the correct library installation path (lib vs. lib64)
> +using uname(1) breaks in cross compilation scenarios where word widths
> +differ between the host and target system.
> +
> +Instead, source the information from the compilers '-dumpmachine'
> +option (supported by both GCC and Clang).
> +
> +We call this the "host" architecture, using the same nomenclature as
> +Autotools (--host configure option).
> +

Please add:

Upstream: https://github.com/libbpf/libbpf/commit/68e6f83f223ebf3fbf0d94c0f4592e5e6773f0c1

> +Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>

Could you send a v2 with those changes? I was about to do the changes
myself, but I really don't know which build failure this patch is
fixing so I couldn't fix that up myself in the commit log.

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4] package/libbpf: fix cross compilation for 32-bit targets

[Tobias Waldekranz]

On ons, okt 26, 2022 at 22:00, Thomas Petazzoni via buildroot <buildroot@buildroot.org> wrote:
> Hello Tobias,
>
> Thanks for this patch!

Thank you for reviewing!

> On Thu, 20 Oct 2022 16:14:09 +0200
> Tobias Waldekranz <tobias@waldekranz.com> wrote:
>
>> Add upstream patch that sources the library path (lib vs. lib64) from
>> the compiler rather than from uname(1).
>
> Could you copy/paste the details of the build failure that was
> occurring, and provide details on the context it was occurring?
>
> Indeed, when looking at the results of our autobuilders in terms of
> failures when building libbpf, I don't see anything relevant:
>
>   http://autobuild.buildroot.net/?reason=libbpf%
>
> In recent months, we only had build failures on the S390x architecture,
> that don't seem related to this.

Sorry, I should have explained the issue better:

Building libbpf "works" without this patch, so I'm not surprised that
there are no autobuild errors. It is just that shared objects and
pkg-config files are always (assuming a 64-bit build system) installed
to /lib64 in target & staging.

If you then try to build something that _depends_ on libbpf, pkg-config
won't be able to find it since /lib64 is not in its path. Hence why I
stumbled upon this - kmemd was the first package to depend on libbpf.

Here's a log when building kmemd for 32-bit PowerPC without this patch:

~/src/buildroot/x-ppc$ make kmemd
>>> kmemd 1.0.0 Configuring
(cd /home/wkz/src/buildroot/x-ppc/build/kmemd-1.0.0/ && rm -rf config.cache && PATH="/home/wkz/src/buildroot/x-ppc/host/bin:/home/wkz/src/buildroot/x-ppc/host/sbin:/home/wkz/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin" AR="/home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-gcc-ar" AS="/home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-as" LD="/home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-ld" NM="/home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-gcc-nm" CC="/home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-gcc" GCC="/home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-gcc" CPP="/home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-cpp" CXX="/home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-g++" FC="/home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-gfortran" F77="/home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-gfortran" RANLIB="/home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-gcc-ranlib" READELF="
 /home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-readelf" STRIP="/home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-strip" OBJCOPY="/home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-objcopy" OBJDUMP="/home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-objdump" AR_FOR_BUILD="/usr/bin/ar" AS_FOR_BUILD="/usr/bin/as" CC_FOR_BUILD="/usr/bin/gcc" GCC_FOR_BUILD="/usr/bin/gcc" CXX_FOR_BUILD="/usr/bin/g++" LD_FOR_BUILD="/usr/bin/ld" CPPFLAGS_FOR_BUILD="-I/home/wkz/src/buildroot/x-ppc/host/include" CFLAGS_FOR_BUILD="-O2 -I/home/wkz/src/buildroot/x-ppc/host/include" CXXFLAGS_FOR_BUILD="-O2 -I/home/wkz/src/buildroot/x-ppc/host/include" LDFLAGS_FOR_BUILD="-L/home/wkz/src/buildroot/x-ppc/host/lib -Wl,-rpath,/home/wkz/src/buildroot/x-ppc/host/lib" FCFLAGS_FOR_BUILD="" DEFAULT_ASSEMBLER="/home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-as" DEFAULT_LINKER="/home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-ld" CPPFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
 " CFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -Os -g0 -D_FORTIFY_SOURCE=1" CXXFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -Os -g0 -D_FORTIFY_SOURCE=1" LDFLAGS="" FCFLAGS=" -Os -g0" FFLAGS=" -Os -g0" PKG_CONFIG="/home/wkz/src/buildroot/x-ppc/host/bin/pkg-config" STAGING_DIR="/home/wkz/src/buildroot/x-ppc/host/powerpc-buildroot-linux-gnu/sysroot" INTLTOOL_PERL=/usr/bin/perl ac_cv_lbl_unaligned_fail=no ac_cv_func_mmap_fixed_mapped=yes ac_cv_func_memcmp_working=yes ac_cv_have_decl_malloc=yes gl_cv_func_malloc_0_nonnull=yes ac_cv_func_malloc_0_nonnull=yes ac_cv_func_calloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes lt_cv_sys_lib_search_path_spec="" ac_cv_c_bigendian=yes   CONFIG_SITE=/dev/null ./configure --target=powerpc-buildroot-linux-gnu --host=powerpc-buildroot-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --localstatedir=/var --program-prefix="" --disable-gtk-doc --disable-gtk-
 doc-html --disable-doc --disable-docs --disable-documentation --with-xmlto=no --with-fop=no --disable-dependency-tracking --enable-ipv6 --disable-nls --disable-static --enable-shared   )
configure: WARNING: unrecognized options: --disable-gtk-doc, --disable-gtk-doc-html, --disable-doc, --disable-docs, --disable-documentation, --with-xmlto, --with-fop, --enable-ipv6, --disable-nls, --disable-static, --enable-shared
checking for powerpc-buildroot-linux-gnu-gcc... /home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether /home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-gcc accepts -g... yes
checking for /home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-gcc option to enable C11 features... none needed
checking whether /home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-gcc understands -c and -o together... yes
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for wchar.h... yes
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether _XOPEN_SOURCE should be defined... no
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for powerpc-buildroot-linux-gnu-strip... /home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-strip
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports the include directive... yes (GNU style)
checking whether make supports nested variables... yes
checking dependency style of /home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-gcc... none
checking whether make supports nested variables... (cached) yes
checking for powerpc-buildroot-linux-gnu-gcc... (cached) /home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-gcc
checking whether the compiler supports GNU C... (cached) yes
checking whether /home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-gcc accepts -g... (cached) yes
checking for /home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-gcc option to enable C11 features... (cached) none needed
checking whether /home/wkz/src/buildroot/x-ppc/host/bin/powerpc-linux-gcc understands -c and -o together... (cached) yes
checking pkg-config is at least version 0.9.0... yes
checking for libbpf >= 1.0.0... no
configure: error: Package requirements (libbpf >= 1.0.0) were not met:

Package 'libbpf', required by 'virtual:world', not found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables libbpf_CFLAGS
and libbpf_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
make[1]: *** [package/pkg-generic.mk:283: /home/wkz/src/buildroot/x-ppc/build/kmemd-1.0.0/.stamp_configured] Error 1
make: *** [Makefile:23: _all] Error 2

And this is the source of the problem:

~/src/buildroot/x-ppc$ find host/powerpc-buildroot-linux-gnu/sysroot/ -name libbpf.pc
host/powerpc-buildroot-linux-gnu/sysroot/usr/lib64/pkgconfig/libbpf.pc

>>  ...cross-compilation-for-32-bit-targets.patch | 37 +++++++++++++++++++
>>  1 file changed, 37 insertions(+)
>>  create mode 100644 package/libbpf/1.0.1/0001-Makefile-Fix-cross-compilation-for-32-bit-targets.patch
>> 
>> diff --git a/package/libbpf/1.0.1/0001-Makefile-Fix-cross-compilation-for-32-bit-targets.patch b/package/libbpf/1.0.1/0001-Makefile-Fix-cross-compilation-for-32-bit-targets.patch
>> new file mode 100644
>> index 0000000000..3730b2fa41
>
> Please put the patch directly in package/libbpf/. Putting it in a
> 1.0.1/ sub-directory is not needed. We only do that for packages where
> multiple versions are used (like package/gcc, package/binutils for
> example).

Will fix in v2.

>> --- /dev/null
>> +++ b/package/libbpf/1.0.1/0001-Makefile-Fix-cross-compilation-for-32-bit-targets.patch
>> @@ -0,0 +1,37 @@
>> +From 68e6f83f223ebf3fbf0d94c0f4592e5e6773f0c1 Mon Sep 17 00:00:00 2001
>> +From: Tobias Waldekranz <tobias@waldekranz.com>
>> +Date: Fri, 14 Oct 2022 21:14:14 +0200
>> +Subject: [PATCH] Makefile: Fix cross-compilation for 32-bit targets
>> +
>> +Determining the correct library installation path (lib vs. lib64)
>> +using uname(1) breaks in cross compilation scenarios where word widths
>> +differ between the host and target system.
>> +
>> +Instead, source the information from the compilers '-dumpmachine'
>> +option (supported by both GCC and Clang).
>> +
>> +We call this the "host" architecture, using the same nomenclature as
>> +Autotools (--host configure option).
>> +
>
> Please add:
>
> Upstream: https://github.com/libbpf/libbpf/commit/68e6f83f223ebf3fbf0d94c0f4592e5e6773f0c1

Sure thing.

>> +Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
>
> Could you send a v2 with those changes? I was about to do the changes
> myself, but I really don't know which build failure this patch is
> fixing so I couldn't fix that up myself in the commit log.
>
> Thanks a lot!
>
> Thomas
> -- 
> Thomas Petazzoni, co-owner and CEO, Bootlin
> Embedded Linux and Kernel engineering and training
> https://bootlin.com
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4] package/libbpf: fix cross compilation for 32-bit targets

[Thomas Petazzoni via buildroot]

On Wed, 26 Oct 2022 22:00:09 +0200
Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:

> Could you copy/paste the details of the build failure that was
> occurring, and provide details on the context it was occurring?

By building kmemd, I figured out what the issue was, and it's now
clear. I have applied your PATCH 1/4 with an extended explanation.

Thanks!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4] package/libbpf: fix cross compilation for 32-bit targets

[Thomas Petazzoni via buildroot]

On Thu, 20 Oct 2022 16:14:09 +0200
Tobias Waldekranz <tobias@waldekranz.com> wrote:

> Add upstream patch that sources the library path (lib vs. lib64) from
> the compiler rather than from uname(1).
> 
> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
> ---
>  ...cross-compilation-for-32-bit-targets.patch | 37 +++++++++++++++++++
>  1 file changed, 37 insertions(+)
>  create mode 100644 package/libbpf/1.0.1/0001-Makefile-Fix-cross-compilation-for-32-bit-targets.patch

Thanks, applied with a rework commit log:

    package/libbpf: install in the correct lib directory
    
    The libbpf build system currently uses the output of "uname -m" to
    determine if the library should be installed in "lib" or
    "lib64". However, uname -m returns the architecture of the build
    machine, which often has nothing to do with the target CPU
    architecture.
    
    A patch has been submitted and accepted upstream to address this
    issue, by using the $(CC) -dumpmachine output instead. This ensures
    libbpf is installed in either "lib" or "lib64" depending on the
    bitness of the target CPU architecture.
    
    Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

The patch was also moved away from the version-specific directory, and
the upstream status of the patch was added in the patch itself.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 2/4] package/libbpf: remove architecture restrictions

[Tobias Waldekranz]

Since 3145adfb69ba, libbpf depends on Linux headers >= 4.13. This
requirement renders the explicit list of supported architectures,
previously added in f693354c30bd overly restrictive, as the syscall
number for bpf(2) has been defined since Linux 3.18.

f693354c30bd was introduced to fix a build issue where a toolchain
using very old kernel headers (3.13) failed to build libbpf for ARM.

Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
---
 package/libbpf/Config.in | 11 -----------
 1 file changed, 11 deletions(-)

diff --git a/package/libbpf/Config.in b/package/libbpf/Config.in
index b3d6e44c6a..1465366c9e 100644
--- a/package/libbpf/Config.in
+++ b/package/libbpf/Config.in
@@ -1,15 +1,5 @@
-config BR2_PACKAGE_LIBBPF_ARCH_SUPPORTS
-	bool
-	# see src/bpf.c
-	default y if BR2_arc
-	default y if BR2_aarch64 || BR2_aarch64_be
-	default y if BR2_i386 || BR2_x86_64
-	default y if BR2_sparc || BR2_sparc64
-	default y if BR2_s390x
-
 config BR2_PACKAGE_LIBBPF
 	bool "libbpf"
-	depends on BR2_PACKAGE_LIBBPF_ARCH_SUPPORTS
 	depends on BR2_TOOLCHAIN_HAS_SYNC_4
 	depends on BR2_USE_WCHAR # elfutils
 	depends on !BR2_STATIC_LIBS # elfutils
@@ -27,7 +17,6 @@ config BR2_PACKAGE_LIBBPF
 	  https://github.com/libbpf/libbpf
 
 comment "libbpf needs a uClibc or glibc toolchain w/ wchar, dynamic library, threads, headers >= 4.13"
-	depends on BR2_PACKAGE_LIBBPF_ARCH_SUPPORTS
 	depends on BR2_TOOLCHAIN_HAS_SYNC_4
 	depends on !BR2_USE_WCHAR || BR2_STATIC_LIBS \
 		|| !BR2_TOOLCHAIN_HAS_THREADS \
-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 2/4] package/libbpf: remove architecture restrictions

[Thomas Petazzoni via buildroot]

Hello Tobias,

On Thu, 20 Oct 2022 16:14:10 +0200
Tobias Waldekranz <tobias@waldekranz.com> wrote:

> Since 3145adfb69ba, libbpf depends on Linux headers >= 4.13. This
> requirement renders the explicit list of supported architectures,
> previously added in f693354c30bd overly restrictive, as the syscall
> number for bpf(2) has been defined since Linux 3.18.
> 
> f693354c30bd was introduced to fix a build issue where a toolchain
> using very old kernel headers (3.13) failed to build libbpf for ARM.
> 
> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
> ---
>  package/libbpf/Config.in | 11 -----------
>  1 file changed, 11 deletions(-)

It is not easy to check if the bpf syscall was indeed wired up in all
architectures we support, but let's assume it's the case as of 4.13 :-)

I have applied, with a slightly improved commit log:

    package/libbpf: remove architecture restrictions
    
    Since Buildroot commit 3145adfb69ba ("package/libbpf: needs headers >=
    4.13"), libbpf depends on Linux headers >= 4.13. This requirement
    renders the explicit list of supported architectures, previously added
    in f693354c30bd overly restrictive, as the syscall number for bpf(2)
    has been defined since Linux 3.18.
    
    Commit f693354c30bd ("package/libbpf: add
    BR2_PACKAGE_LIBBPF_ARCH_SUPPORTS") was introduced to fix a build issue
    where a toolchain using very old kernel headers (3.13) failed to build
    libbpf for ARM, but these architecture dependencies are no longer
    needed due to the bump on the kernel headers version requirement.

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 3/4] package/libbpf: extract dependencies to separate kconfig symbol

[Tobias Waldekranz]

This makes it obvious that the comment is just the negation of the
dependency requirements. It also makes it easier for other packages to
depend on libbpf.

Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
---
 package/libbpf/Config.in | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/package/libbpf/Config.in b/package/libbpf/Config.in
index 1465366c9e..7e816c193d 100644
--- a/package/libbpf/Config.in
+++ b/package/libbpf/Config.in
@@ -1,11 +1,16 @@
-config BR2_PACKAGE_LIBBPF
-	bool "libbpf"
+config BR2_PACKAGE_LIBBPF_SUPPORTED
+	bool
 	depends on BR2_TOOLCHAIN_HAS_SYNC_4
 	depends on BR2_USE_WCHAR # elfutils
 	depends on !BR2_STATIC_LIBS # elfutils
 	depends on BR2_TOOLCHAIN_HAS_THREADS # elfutils
 	depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_13
 	depends on BR2_TOOLCHAIN_USES_UCLIBC || BR2_TOOLCHAIN_USES_GLIBC # elfutils
+	default y
+
+config BR2_PACKAGE_LIBBPF
+	bool "libbpf"
+	depends on BR2_PACKAGE_LIBBPF_SUPPORTED
 	select BR2_PACKAGE_ELFUTILS
 	select BR2_PACKAGE_ZLIB
 	help
@@ -17,8 +22,4 @@ config BR2_PACKAGE_LIBBPF
 	  https://github.com/libbpf/libbpf
 
 comment "libbpf needs a uClibc or glibc toolchain w/ wchar, dynamic library, threads, headers >= 4.13"
-	depends on BR2_TOOLCHAIN_HAS_SYNC_4
-	depends on !BR2_USE_WCHAR || BR2_STATIC_LIBS \
-		|| !BR2_TOOLCHAIN_HAS_THREADS \
-		|| !BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_13 \
-		|| !(BR2_TOOLCHAIN_USES_UCLIBC || BR2_TOOLCHAIN_USES_GLIBC)
+	depends on !BR2_PACKAGE_LIBBPF_SUPPORTED
-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/4] package/libbpf: extract dependencies to separate kconfig symbol

[Thomas Petazzoni via buildroot]

Hello Tobias,

On Thu, 20 Oct 2022 16:14:11 +0200
Tobias Waldekranz <tobias@waldekranz.com> wrote:

> This makes it obvious that the comment is just the negation of the
> dependency requirements. It also makes it easier for other packages to
> depend on libbpf.
> 
> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
> ---
>  package/libbpf/Config.in | 15 ++++++++-------
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/package/libbpf/Config.in b/package/libbpf/Config.in
> index 1465366c9e..7e816c193d 100644
> --- a/package/libbpf/Config.in
> +++ b/package/libbpf/Config.in
> @@ -1,11 +1,16 @@
> -config BR2_PACKAGE_LIBBPF
> -	bool "libbpf"
> +config BR2_PACKAGE_LIBBPF_SUPPORTED
> +	bool
>  	depends on BR2_TOOLCHAIN_HAS_SYNC_4
>  	depends on BR2_USE_WCHAR # elfutils
>  	depends on !BR2_STATIC_LIBS # elfutils
>  	depends on BR2_TOOLCHAIN_HAS_THREADS # elfutils
>  	depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_13
>  	depends on BR2_TOOLCHAIN_USES_UCLIBC || BR2_TOOLCHAIN_USES_GLIBC # elfutils

I'm afraid, but we don't do this in Buildroot, in none of our packages.
I think our rationale is that by duplicating these dependencies, it is
easier to maintain the Config.in comment in the packages that select
BR2_PACKAGE_LIBBPF.

I agree it's a very arbitrary choice, but we really strongly want
things to be consistent between all Buildroot packages, so we cannot
change this for just one package. If we want to change this, it needs
to be discussed (advantages vs. drawbacks), then the documentation
needs to be updated, and all packages changed.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/4] package/libbpf: extract dependencies to separate kconfig symbol

[Tobias Waldekranz]

On ons, okt 26, 2022 at 22:15, Thomas Petazzoni via buildroot <buildroot@buildroot.org> wrote:
> Hello Tobias,
>
> On Thu, 20 Oct 2022 16:14:11 +0200
> Tobias Waldekranz <tobias@waldekranz.com> wrote:
>
>> This makes it obvious that the comment is just the negation of the
>> dependency requirements. It also makes it easier for other packages to
>> depend on libbpf.
>> 
>> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
>> ---
>>  package/libbpf/Config.in | 15 ++++++++-------
>>  1 file changed, 8 insertions(+), 7 deletions(-)
>> 
>> diff --git a/package/libbpf/Config.in b/package/libbpf/Config.in
>> index 1465366c9e..7e816c193d 100644
>> --- a/package/libbpf/Config.in
>> +++ b/package/libbpf/Config.in
>> @@ -1,11 +1,16 @@
>> -config BR2_PACKAGE_LIBBPF
>> -	bool "libbpf"
>> +config BR2_PACKAGE_LIBBPF_SUPPORTED
>> +	bool
>>  	depends on BR2_TOOLCHAIN_HAS_SYNC_4
>>  	depends on BR2_USE_WCHAR # elfutils
>>  	depends on !BR2_STATIC_LIBS # elfutils
>>  	depends on BR2_TOOLCHAIN_HAS_THREADS # elfutils
>>  	depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_13
>>  	depends on BR2_TOOLCHAIN_USES_UCLIBC || BR2_TOOLCHAIN_USES_GLIBC # elfutils
>
> I'm afraid, but we don't do this in Buildroot, in none of our packages.
> I think our rationale is that by duplicating these dependencies, it is
> easier to maintain the Config.in comment in the packages that select
> BR2_PACKAGE_LIBBPF.

Fair enough, I will drop this change in v2 and copy the information to
kmemd.mk instead. Is there a convention for how to comment dependencies
that stem from grandparent packages? E.g. v2, kmemd.mk will declare:

   depends on BR2_USE_WCHAR # <comment>

as libbpf requires it, but only because of its dependency on
elfutils. So what is the proper <comment> in this case?

"elfutils" or "libbpf"? Or maybe something like "elfutils->libbpf"?

> I agree it's a very arbitrary choice, but we really strongly want
> things to be consistent between all Buildroot packages, so we cannot
> change this for just one package. If we want to change this, it needs
> to be discussed (advantages vs. drawbacks), then the documentation
> needs to be updated, and all packages changed.

Completely understand. As a Buildroot user, I really appreciate that
consistency!

> Best regards,
>
> Thomas
> -- 
> Thomas Petazzoni, co-owner and CEO, Bootlin
> Embedded Linux and Kernel engineering and training
> https://bootlin.com
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/4] package/libbpf: extract dependencies to separate kconfig symbol

[Thomas Petazzoni via buildroot]

Hello Tobias,

On Wed, 26 Oct 2022 23:14:08 +0200
Tobias Waldekranz <tobias@waldekranz.com> wrote:

> Fair enough, I will drop this change in v2 and copy the information to
> kmemd.mk instead. Is there a convention for how to comment dependencies
> that stem from grandparent packages? E.g. v2, kmemd.mk will declare:

No need to send a v2, I already applied the patches locally, did the few
fixes, I will push them soon.

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 4/4] package/kmemd: new package

[Tobias Waldekranz]

kmemd let's you inspect a live Linux kernel's memory using GDB.

Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
---
 package/Config.in        |  1 +
 package/kmemd/Config.in  | 11 +++++++++++
 package/kmemd/kmemd.hash |  5 +++++
 package/kmemd/kmemd.mk   | 20 ++++++++++++++++++++
 4 files changed, 37 insertions(+)
 create mode 100644 package/kmemd/Config.in
 create mode 100644 package/kmemd/kmemd.hash
 create mode 100644 package/kmemd/kmemd.mk

diff --git a/package/Config.in b/package/Config.in
index e3a34d6e97..ebafe11dea 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -111,6 +111,7 @@ menu "Debugging, profiling and benchmark"
 	source "package/iozone/Config.in"
 	source "package/kexec/Config.in"
 	source "package/kexec-lite/Config.in"
+	source "package/kmemd/Config.in"
 	source "package/kvm-unit-tests/Config.in"
 	source "package/kyua/Config.in"
 	source "package/latencytop/Config.in"
diff --git a/package/kmemd/Config.in b/package/kmemd/Config.in
new file mode 100644
index 0000000000..2190488b0f
--- /dev/null
+++ b/package/kmemd/Config.in
@@ -0,0 +1,11 @@
+config BR2_PACKAGE_KMEMD
+	bool "kmemd"
+	depends on BR2_PACKAGE_LIBBPF_SUPPORTED
+	select BR2_PACKAGE_LIBBPF
+	help
+	  Explore a live Linux kernel's memory using GDB
+
+	  https://github.com/wkz/kmemd
+
+comment "kmemd needs libbpf"
+	depends on !BR2_PACKAGE_LIBBPF_SUPPORTED
diff --git a/package/kmemd/kmemd.hash b/package/kmemd/kmemd.hash
new file mode 100644
index 0000000000..60b8589dd2
--- /dev/null
+++ b/package/kmemd/kmemd.hash
@@ -0,0 +1,5 @@
+# Locally calculated
+md5  9954bf82279eeb0da016654689f69ac2  kmemd-1.0.0.tar.gz
+sha1  3ae3bdceb70d674f41f56cd489c7497944b9b0f0  kmemd-1.0.0.tar.gz
+sha256  519ac3cdd367acee5090eec3b7e08400724f9b84486b191f3af534bd7cffca70  kmemd-1.0.0.tar.gz
+sha256  8177f97513213526df2cf6184d8ff986c675afb514d4e68a404010521b880643  COPYING
diff --git a/package/kmemd/kmemd.mk b/package/kmemd/kmemd.mk
new file mode 100644
index 0000000000..902941b981
--- /dev/null
+++ b/package/kmemd/kmemd.mk
@@ -0,0 +1,20 @@
+################################################################################
+#
+# kmemd
+#
+################################################################################
+
+KMEMD_VERSION = 1.0.0
+KMEMD_SITE = https://github.com/wkz/kmemd/releases/download/$(KMEMD_VERSION)
+KMEMD_LICENSE = GPL-2.0
+KMEMD_LICENSE_FILES = COPYING
+KMEMD_DEPENDENCIES = libbpf
+
+define KMEMD_LINUX_CONFIG_FIXUPS
+	$(call KCONFIG_ENABLE_OPT,CONFIG_BPF_SYSCALL)
+	$(call KCONFIG_ENABLE_OPT,CONFIG_FTRACE)
+	$(call KCONFIG_ENABLE_OPT,CONFIG_KPROBES)
+	$(call KCONFIG_ENABLE_OPT,CONFIG_PERF_EVENTS)
+endef
+
+$(eval $(autotools-package))
-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 4/4] package/kmemd: new package

[Thomas Petazzoni via buildroot]

On Thu, 20 Oct 2022 16:14:12 +0200
Tobias Waldekranz <tobias@waldekranz.com> wrote:

> kmemd let's you inspect a live Linux kernel's memory using GDB.
> 
> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>

I have applied a patch, with a few small changes.

> ---
>  package/Config.in        |  1 +
>  package/kmemd/Config.in  | 11 +++++++++++
>  package/kmemd/kmemd.hash |  5 +++++
>  package/kmemd/kmemd.mk   | 20 ++++++++++++++++++++
>  4 files changed, 37 insertions(+)

I added an entry in the DEVELOPERS file for this package, so that we
know you are the contact. You will receive e-mails if there are build
failures or CVEs affecting this package, and when new releases are made
upstream (even though I suppose you are the upstream maintainer, so you
should already know!)

> diff --git a/package/kmemd/Config.in b/package/kmemd/Config.in
> new file mode 100644
> index 0000000000..2190488b0f
> --- /dev/null
> +++ b/package/kmemd/Config.in
> @@ -0,0 +1,11 @@
> +config BR2_PACKAGE_KMEMD
> +	bool "kmemd"
> +	depends on BR2_PACKAGE_LIBBPF_SUPPORTED

Changed to repeat the dependencies of libbpf.

> +	select BR2_PACKAGE_LIBBPF
> +	help
> +	  Explore a live Linux kernel's memory using GDB
> +
> +	  https://github.com/wkz/kmemd
> +
> +comment "kmemd needs libbpf"
> +	depends on !BR2_PACKAGE_LIBBPF_SUPPORTED

This comment was not correct: you are selecting libbpf, so you don't
need to say that you need it. Instead, I've added our usual comment,
which corresponds to the dependencies inherited from libbpf.

> diff --git a/package/kmemd/kmemd.hash b/package/kmemd/kmemd.hash
> new file mode 100644
> index 0000000000..60b8589dd2
> --- /dev/null
> +++ b/package/kmemd/kmemd.hash
> @@ -0,0 +1,5 @@
> +# Locally calculated
> +md5  9954bf82279eeb0da016654689f69ac2  kmemd-1.0.0.tar.gz
> +sha1  3ae3bdceb70d674f41f56cd489c7497944b9b0f0  kmemd-1.0.0.tar.gz
> +sha256  519ac3cdd367acee5090eec3b7e08400724f9b84486b191f3af534bd7cffca70  kmemd-1.0.0.tar.gz

When we have a sha256, md5/sha1 hashes are not needed, so I dropped them.

Applied with those changes, thanks!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 4/4] package/kmemd: new package

[Tobias Waldekranz]

On tor, okt 27, 2022 at 08:49, Thomas Petazzoni via buildroot <buildroot@buildroot.org> wrote:
...
> Applied with those changes, thanks!

Thanks for going the extra mile!

Hopefully the next series won't require as much work from your end.

--
Tobias
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 4/4] package/kmemd: new package

[Thomas Petazzoni via buildroot]

On Thu, 27 Oct 2022 22:27:25 +0200
Tobias Waldekranz <tobias@waldekranz.com> wrote:

> Thanks for going the extra mile!
> 
> Hopefully the next series won't require as much work from your end.

Oh, no worries, your patch series was actually very good! There was not
much to adjust before committing. Looking forward for more
contributions from you!

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot