[PATCH v4] Add recipe for linux kselftest

[Vijai Kumar K]

Kselftest is a set of unit and regression tests under the
tools/testing/selftests/ directory of the Linux kernel. These are used
for testing individual code paths in the kernel.

Kselftest is not debianized and is not available as part of the official
Debian repository.

This patch provides a recipe to build kselftest from the linux source of
your choice.

Sometimes developers/testers tend to use the latest version of selftests
from Linux upstream stable releases for testing and hence the need for a
separate recipe instead of being part of the linux recipe of ISAR.

Some kselftest test cases build are known to break in certain linux
versions, this has to be addressed upstream. Right now kselftest build
succeeds even if atleast one of the testcase case build succeeds.

You can change that by setting KSELFTEST_FORCE_TARGETS=1.

TARGETS, TARGETS_SKIP, FORCE_TARGETS can be set using the appropriate
KSELFTEST_* recipe variable.

Signed-off-by: Vijai Kumar K <Vijaikumar_...@mentor.com>
---
Changes since v3:
- Remove libnuma-dev. Since it is not available in stretch.
- remove entry in isar-image-debug. Added to CI image using IMAGE_INSTALL.

Changes since v2:
- Use deb_debianize instead of individual calls for changelog, compat & control.
- Add package to isar-image-debug

Changes since v1:
- Addressed review comments in v1
- Used debianize APIs for control, compat and changelog.
- Moved Depends & S definitions to include file.
- Added cross compilation bits in rules.
- Change clang, llvm to clang:native & llvm:native

.../kselftest/kselftest_5.6.13.bb | 11 ++++
meta/recipes-kernel/kselftest/files/rules | 41 +++++++++++++
meta/recipes-kernel/kselftest/kselftest.inc | 58 +++++++++++++++++++
scripts/ci_build.sh | 1 +
4 files changed, 111 insertions(+)
create mode 100644 meta-isar/recipes-kernel/kselftest/kselftest_5.6.13.bb
create mode 100755 meta/recipes-kernel/kselftest/files/rules
create mode 100644 meta/recipes-kernel/kselftest/kselftest.inc

diff --git a/meta-isar/recipes-kernel/kselftest/kselftest_5.6.13.bb b/meta-isar/recipes-kernel/kselftest/kselftest_5.6.13.bb
new file mode 100644
index 0000000..0c9818a
--- /dev/null
+++ b/meta-isar/recipes-kernel/kselftest/kselftest_5.6.13.bb
@@ -0,0 +1,11 @@
+# Kselftest package
+#
+# This software is a part of ISAR.
+# Copyright (c) Mentor Graphics, a Siemens business, 2020
+#
+# SPDX-License-Identifier: MIT
+
+require recipes-kernel/kselftest/kselftest.inc
+
+SRC_URI += "https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-${PV}.tar.xz"
+SRC_URI[sha256sum] = "f125d79c8f6974213638787adcad6b575bbd35a05851802fd83f622ec18ff987"
diff --git a/meta/recipes-kernel/kselftest/files/rules b/meta/recipes-kernel/kselftest/files/rules
new file mode 100755
index 0000000..776d341
--- /dev/null
+++ b/meta/recipes-kernel/kselftest/files/rules
@@ -0,0 +1,41 @@
+#!/usr/bin/make -f
+
+# Debian rules for Kselftest build
+#
+# This software is a part of ISAR.
+# Copyright (c) Mentor, A Siemens Business
+#
+# SPDX-License-Identifier: MIT
+
+deb_top_dir:=$(CURDIR)/debian
+kselftest_install_dir :=$(deb_top_dir)/kselftest/usr/libexec/kselftest
+export CROSS_COMPILE=$(DEB_HOST_GNU_TYPE)-
+
+ifeq ($(DEB_HOST_GNU_CPU), arm)
+export ARCH=arm
+endif
+ifeq ($(DEB_HOST_GNU_CPU), aarch64)
+export ARCH=arm64
+endif
+ifeq ($(DEB_HOST_GNU_CPU), riscv64)
+export ARCH=riscv
+endif
+ifneq (,$(findstring 86,$(DEB_HOST_GNU_CPU)))
+export ARCH=x86
+endif
+
+PARALLEL_BUILD=-j $(shell echo $$(($$(nproc) * 2)))
+
+override_dh_auto_build:
+ $(MAKE) defconfig
+ $(MAKE) $(PARALLEL_BUILD) -C tools/testing/selftests/ ${KSELFTEST_ARGS}
+
+override_dh_auto_install:
+ mkdir -p ${kselftest_install_dir}
+ cd tools/testing/selftests/ && KSFT_INSTALL_PATH=${kselftest_install_dir} $(MAKE) $(PARALLEL_BUILD) install ${KSELFTEST_ARGS}
+
+override_dh_auto_clean:
+ rm -rf ${deb_top_dir}/kselftest/
+
+%:
+ CFLAGS= LDFLAGS= dh $@ --parallel
diff --git a/meta/recipes-kernel/kselftest/kselftest.inc b/meta/recipes-kernel/kselftest/kselftest.inc
new file mode 100644
index 0000000..2a76028
--- /dev/null
+++ b/meta/recipes-kernel/kselftest/kselftest.inc
@@ -0,0 +1,58 @@
+# Kselftest package for Linux
+#
+# This software is a part of ISAR.
+# Copyright (c) Mentor Graphics, a Siemens Business, 2020
+#
+# SPDX-License-Identifier: MIT
+
+inherit dpkg
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+# Some test-cases like memfd compilation failed in cross-compilation.
+# Force native compilation for now to have consistent output across
+# ISAR native/cross compilation setups.
+ISAR_CROSS_COMPILE = "0"
+
+DESCRIPTION ?= "Kernel selftests from Linux kernel ${PV}"
+
+DEBIAN_BUILD_DEPENDS ?= " \
+ rsync, \
+ flex, \
+ bison, \
+ fuse, \
+ libelf-dev:native, \
+ libcap-ng-dev:native, \
+ libpopt-dev:native, \
+ libcap-dev:native, \
+ libmount-dev:native, \
+ libfuse-dev:native, \
+ libmnl-dev:native, \
+ pkg-config, \
+ clang:native, \
+ llvm:native, \
+"
+
+SRC_URI += "file://rules"
+S = "${WORKDIR}/linux-${PV}"
+
+KSELFTEST_TARGETS ?= ""
+KSELFTEST_SKIP_TARGETS ?= ""
+KSELFTEST_FORCE_TARGETS ?= "0"
+
+do_prepare_build[cleandirs] += "${S}/debian"
+do_prepare_build() {
+ deb_debianize
+}
+
+dpkg_runbuild_prepend() {
+ if [ -n "${KSELFTEST_TARGETS}" ];then
+ export KSELFTEST_ARGS="TARGETS=\"${KSELFTEST_TARGETS}\""
+ fi
+ if [ ${KSELFTEST_FORCE_TARGETS} -eq 1 ];then
+ export KSELFTEST_ARGS="${KSELFTEST_ARGS} FORCE_TARGETS=1"
+ fi
+ if [ -n "${KSELFTEST_SKIP_TARGETS}" ];then
+ export KSELFTEST_ARGS="${KSELFTEST_ARGS} SKIP_TARGETS=\"${KSELFTEST_SKIP_TARGETS}\""
+ fi
+}
diff --git a/scripts/ci_build.sh b/scripts/ci_build.sh
index c0a032e..2d06543 100755
--- a/scripts/ci_build.sh
+++ b/scripts/ci_build.sh
@@ -143,6 +143,7 @@ cat >>conf/local.conf <<EOF
ISAR_ENABLE_COMPAT_ARCH_amd64 = "1"
ISAR_ENABLE_COMPAT_ARCH_arm64 = "1"
ISAR_ENABLE_COMPAT_ARCH_debian-stretch_amd64 = "0"
+IMAGE_INSTALL += "kselftest"
EOF

if [ -n "$CROSS_BUILD" ]; then
--
2.17.1

[Henning Schild]

Did not follow the thread and coming late to the table. Did anyone
consider pushing this upstream into the kernel?

For the kernel itself we eventually failed. But because it turned out
to be too complicated to find a generic debianization that fits all the
needs. For a tool it might be a different story.

Henning

Am Mon, 2 Nov 2020 12:55:11 +0530
schrieb Vijai Kumar K <Vijaikumar_...@mentor.com>:

[vijaikumar....@gmail.com]

On Thursday, November 5, 2020 at 2:14:50 AM UTC+5:30 Henning Schild wrote:

Did not follow the thread and coming late to the table. Did anyone
consider pushing this upstream into the kernel?

No. Atleast, I did not try it.

[Henning Schild]

Am Wed, 4 Nov 2020 22:17:29 -0800 (PST)
schrieb "vijaikumar....@gmail.com" <vijaikumar....@gmail.com>:

> On Thursday, November 5, 2020 at 2:14:50 AM UTC+5:30 Henning Schild
> wrote:
>
> > Did not follow the thread and coming late to the table. Did anyone
> > consider pushing this upstream into the kernel?
> >
>
> No. Atleast, I did not try it.

Ok, we already have other tools like perf and the kernel does not seem
to like debianizations in its tree.

Henning

[vijaikumar....@gmail.com]

On Friday, November 6, 2020 at 7:08:25 PM UTC+5:30 Henning Schild wrote:

Am Wed, 4 Nov 2020 22:17:29 -0800 (PST)
schrieb "vijaikumar....@gmail.com" <vijaikumar....@gmail.com>:

> On Thursday, November 5, 2020 at 2:14:50 AM UTC+5:30 Henning Schild
> wrote:
>
> > Did not follow the thread and coming late to the table. Did anyone
> > consider pushing this upstream into the kernel?
> >
>
> No. Atleast, I did not try it.

Ok, we already have other tools like perf and the kernel does not seem
to like debianizations in its tree.

Henning

Hi Henning,

Is this good to go? Or should we try to do this upstream? Maybe both.

Thanks,

Vijai Kumar K

[Anton Mikanovich]

26.11.2020 21:38, vijaikumar....@gmail.com wrote:

On Friday, November 6, 2020 at 7:08:25 PM UTC+5:30 Henning Schild wrote:

Am Wed, 4 Nov 2020 22:17:29 -0800 (PST)
schrieb "vijaikumar....@gmail.com" <vijaikumar....@gmail.com>:

> On Thursday, November 5, 2020 at 2:14:50 AM UTC+5:30 Henning Schild
> wrote:
>
> > Did not follow the thread and coming late to the table. Did anyone
> > consider pushing this upstream into the kernel?
> >
>
> No. Atleast, I did not try it.

Ok, we already have other tools like perf and the kernel does not seem
to like debianizations in its tree.

Henning

Hi Henning,

Is this good to go? Or should we try to do this upstream? Maybe both.

Thanks,

Vijai Kumar K

Hello, what is the status of this? Can we proceed with apply?

-- 
Anton Mikanovich
Promwad Ltd.
External service provider of ilbers GmbH
Maria-Merian-Str. 8
85521 Ottobrunn, Germany
+49 (89) 122 67 24-0
Commercial register Munich, HRB 214197
General Manager: Baurzhan Ismagulov

[vijaikumar....@gmail.com]

On Monday, February 8, 2021 at 9:03:56 PM UTC+5:30 ami...@ilbers.de wrote:

26.11.2020 21:38, vijaikumar....@gmail.com wrote:

On Friday, November 6, 2020 at 7:08:25 PM UTC+5:30 Henning Schild wrote:

Am Wed, 4 Nov 2020 22:17:29 -0800 (PST)
schrieb "vijaikumar....@gmail.com" <vijaikumar....@gmail.com>:

> On Thursday, November 5, 2020 at 2:14:50 AM UTC+5:30 Henning Schild
> wrote:
>
> > Did not follow the thread and coming late to the table. Did anyone
> > consider pushing this upstream into the kernel?
> >
>
> No. Atleast, I did not try it.

Ok, we already have other tools like perf and the kernel does not seem
to like debianizations in its tree.

Henning

Hi Henning,

Is this good to go? Or should we try to do this upstream? Maybe both.

Thanks,

Vijai Kumar K

Hello, what is the status of this? Can we proceed with apply?

Ok from my end. Lets see what Henning has to say.

[Henning Schild]

Am Tue, 9 Feb 2021 22:34:42 -0800 (PST)

schrieb "vijaikumar....@gmail.com" <vijaikumar....@gmail.com>:

> On Monday, February 8, 2021 at 9:03:56 PM UTC+5:30 ami...@ilbers.de
> wrote:
>
> > 26.11.2020 21:38, vijaikumar....@gmail.com wrote:
> >
> >
> >
> > On Friday, November 6, 2020 at 7:08:25 PM UTC+5:30 Henning Schild
> > wrote:
> >> Am Wed, 4 Nov 2020 22:17:29 -0800 (PST)
> >> schrieb "vijaikumar....@gmail.com" <vijaikumar....@gmail.com>:
> >>
> >> > On Thursday, November 5, 2020 at 2:14:50 AM UTC+5:30 Henning
> >> > Schild wrote:
> >> >
> >> > > Did not follow the thread and coming late to the table. Did
> >> > > anyone consider pushing this upstream into the kernel?
> >> > >
> >> >
> >> > No. Atleast, I did not try it.
> >>
> >> Ok, we already have other tools like perf and the kernel does not
> >> seem to like debianizations in its tree.
> >>
> >> Henning
> >>
> >
> > Hi Henning,
> >
> > Is this good to go? Or should we try to do this upstream? Maybe
> > both.
> >
> > Thanks,
> > Vijai Kumar K
> >
> > Hello, what is the status of this? Can we proceed with apply?
> >
>
>
> Ok from my end. Lets see what Henning has to say.

I did not actually review it. The one question with the mainlining has
been answered. It is not nice but the debianization of the kernel is
isar business.

So for this one question ... good to go.

Henning

[Baurzhan Ismagulov]

On Wed, Feb 10, 2021 at 11:21:46AM +0100, Henning Schild wrote:
> I did not actually review it. The one question with the mainlining has
> been answered. It is not nice but the debianization of the kernel is
> isar business.

Thanks Henning for the feedback.

@Vijai Kumar: After seeing the perf implementation, I wonder whether we could
harmonize towards the existing kernel infrastructure here as well. What do you
think?

With kind regards,
Baurzhan.

[vijaikumar....@gmail.com]

Hi Baurzhan,

I did not get a chance to look at that series yet. Will have a look and get back.

Thanks,

Vijai Kumar K

With kind regards,
Baurzhan.

[vijai kumar]

Hi Baurzhan,

Just had a look at that series. Seems like we backport the necessary
patches for the particular kernel version.
This might be hard here, since the changes might me more.

The original intention to have this package as a separate recipe is to
provide means to use the latest kernel
kselftest testcases. Those seem to be more mature than one available
in lower kernel versions like 4.19.

The changes might be too much to backport making the approach more complicated.

In our usecase we are using the cip kernel, and if someone feels like
some testcases needs to be backported,
it needs to be done in the cip-kernel project and not it ISAR. But
there is no strong requirement from the users
for that, they are just okay with using the version that is available
in the latest kernel. This recipe just makes them
achieve that.

Thanks,
Vijai Kumar K

>
> Thanks,
> Vijai Kumar K
>
>>
>>
>> With kind regards,
>> Baurzhan.
>

> --
> You received this message because you are subscribed to a topic in the Google Groups "isar-users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/isar-users/_GrkFK64py4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to isar-users+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/96f074be-a70e-43d7-9eab-e74be12ed444n%40googlegroups.com.

[vijaikumar....@gmail.com]

Are there any more review comments on this?

[Baurzhan Ismagulov]

Hello Vijai Kumar,

On Tue, Mar 30, 2021 at 02:41:08PM +0530, vijai kumar wrote:
> Just had a look at that series. Seems like we backport the necessary
> patches for the particular kernel version.
> This might be hard here, since the changes might me more.
>
> The original intention to have this package as a separate recipe is to
> provide means to use the latest kernel
> kselftest testcases. Those seem to be more mature than one available
> in lower kernel versions like 4.19.
>
> The changes might be too much to backport making the approach more complicated.
>
> In our usecase we are using the cip kernel, and if someone feels like
> some testcases needs to be backported,
> it needs to be done in the cip-kernel project and not it ISAR. But
> there is no strong requirement from the users
> for that, they are just okay with using the version that is available
> in the latest kernel. This recipe just makes them
> achieve that.

So, this is a trade-off.

On one hand, architecturally it would make sense to bundle all binary packages
in the same source package. The advantages would be avoiding code duplication,
avoiding fetching different kernel sources in case the two are different
(better build time and space efficiency).

On the other hand, separate tool recipes allow shipping the latest tools also
for older kernels. The advantages are independent kernel and tool versions if
different ones are used, avoiding building the kernel if it isn't needed
(better build time and space efficiency).

Personally, I could live with this implementation until we have a better one.
We will play with it and let you know. That said, I still think that in
general, we should strive for "one source -- one recipe" implementation and
find a good way to refactor this one.

Supporting older kernel versions is an important feature; we should be looking
how to support newer ones without creating a mess. If necessary, maybe we could
split the include file into epoch-specific ones (linux-4.19+.inc,
linux-5.4+.inc, etc.). I don't mind if we override upstream packaging
mechanisms in part or even fully for the old versions; for the newer ones, I
agree that we should at least try submitting our changes upstream. Regarding
partial builds, maybe we could have a var choosing which components to build if
e.g. the kernel itself is not necessary.

With kind regards,
Baurzhan.

[Anton Mikanovich]

02.11.2020 10:25, Vijai Kumar K wrote:
> Kselftest is a set of unit and regression tests under the
> tools/testing/selftests/ directory of the Linux kernel. These are used
> for testing individual code paths in the kernel.
>
> Kselftest is not debianized and is not available as part of the official
> Debian repository.
>
> This patch provides a recipe to build kselftest from the linux source of
> your choice.
>
> Sometimes developers/testers tend to use the latest version of selftests
> from Linux upstream stable releases for testing and hence the need for a
> separate recipe instead of being part of the linux recipe of ISAR.
>
> Some kselftest test cases build are known to break in certain linux
> versions, this has to be addressed upstream. Right now kselftest build
> succeeds even if atleast one of the testcase case build succeeds.
>
> You can change that by setting KSELFTEST_FORCE_TARGETS=1.
>
> TARGETS, TARGETS_SKIP, FORCE_TARGETS can be set using the appropriate
> KSELFTEST_* recipe variable.
>
> Signed-off-by: Vijai Kumar K <Vijaikumar_...@mentor.com>

Applied to next, thanks.