From: Miroslav Benes <mbenes@suse.cz>
To: Joe Lawrence <joe.lawrence@redhat.com>
Cc: Marcos Paulo de Souza <mpdesouza@suse.com>,
Shuah Khan <shuah@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Jiri Kosina <jikos@kernel.org>, Petr Mladek <pmladek@suse.com>,
linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
live-patching@vger.kernel.org
Subject: Re: [PATCH v3 2/3] livepatch: Move tests from lib/livepatch to selftests/livepatch
Date: Fri, 8 Dec 2023 09:06:30 +0100 (CET) [thread overview]
Message-ID: <alpine.LSU.2.21.2312080854100.14729@pobox.suse.cz> (raw)
In-Reply-To: <273a86d6-d220-fdcf-3c2f-70516c519ff9@redhat.com>
> > My idea is to abandon this way completely, take the selftests and build
> > and run them on the system right away.
> >
> > Both should be doable, hopefully, if we wire it all correctly... and
> > document it.
> >
> I can't think of why it shouldn't continue to work, even in a future
> where newer livepatching selftests support older kernels. (We would
> just have newer selftests sources backported to test older kernel sources.)
>
> Are there any test cases which truly need to be build on-the-fly? Aside
> from testing different toolchain pieces?
https://github.com/SUSE/qa_test_klp is what we would like to migrate to
selftests to have just one place for all tests.
There is basically just one live patch template and one supporting kernel
module template which is livepatched. The final result is driven by a set
of macros and function parameters. In some cases more modules are compiled
as parts of a test in a loop.
However, I do not think there is anything which truly needs to be built
on-the-fly in the end. Everything can be worked around. Templates may be
abandoned and we would have a live patch and a module(s) per test. Some
tests are probably not worth it and may be removed. So it is a question of
convenience and maintainability. When we, for example, simplified API and
klp_register_patch() was removed, only one place needed to be amended.
Also, the current state in lib/livepatch/ could be simplified with the
proposed infrastructure as some files could be merged together.
Miroslav
next prev parent reply other threads:[~2023-12-08 8:06 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-31 21:10 [PATCH v3 0/3] livepatch: Move modules to selftests and add a new test Marcos Paulo de Souza
2023-10-31 21:10 ` [PATCH v3 1/3] kselftests: lib.mk: Add TEST_GEN_MODS_DIR variable Marcos Paulo de Souza
2023-10-31 21:10 ` [PATCH v3 2/3] livepatch: Move tests from lib/livepatch to selftests/livepatch Marcos Paulo de Souza
2023-12-01 15:27 ` Joe Lawrence
2023-12-06 15:05 ` Miroslav Benes
2023-12-07 15:20 ` Joe Lawrence
2023-12-07 19:19 ` mpdesouza
2023-12-11 21:56 ` Shuah Khan
2023-12-12 2:01 ` Marcos Paulo de Souza
2023-12-08 8:06 ` Miroslav Benes [this message]
2023-12-08 12:43 ` Petr Mladek
2023-10-31 21:10 ` [PATCH v3 3/3] selftests: livepatch: Test livepatching a heavily called syscall Marcos Paulo de Souza
2023-11-30 23:24 ` Shuah Khan
2023-12-01 13:13 ` Marcos Paulo de Souza
2023-12-01 16:38 ` Shuah Khan
2023-12-05 12:52 ` mpdesouza
2023-12-05 15:39 ` Shuah Khan
2023-12-06 14:39 ` Miroslav Benes
2023-12-11 21:53 ` Shuah Khan
2023-12-15 20:36 ` Joe Lawrence
2023-12-18 20:47 ` Shuah Khan
2023-12-20 11:33 ` Marcos Paulo de Souza
2023-11-30 13:42 ` [PATCH v3 0/3] livepatch: Move modules to selftests and add a new test Marcos Paulo de Souza
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LSU.2.21.2312080854100.14729@pobox.suse.cz \
--to=mbenes@suse.cz \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=corbet@lwn.net \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mpdesouza@suse.com \
--cc=pmladek@suse.com \
--cc=shuah@kernel.org \
--cc=svens@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox