From: Richard Palethorpe <rpalethorpe@suse.de>
To: Li Wang <liwang@redhat.com>
Cc: LTP List <ltp@lists.linux.it>
Subject: Re: [LTP] [RFC PATCH] API: Allow testing of kernel features in development
Date: Tue, 21 Dec 2021 13:56:12 +0000 [thread overview]
Message-ID: <875yrif3qd.fsf@suse.de> (raw)
In-Reply-To: <CAEemH2eFg5HVK32hLGrB_OvqN4Ef+QfkdkGebKgEkz--tYYoKA@mail.gmail.com>
Hello Li,
Li Wang <liwang@redhat.com> writes:
> Hi Richard,
>
> On Tue, Dec 21, 2021 at 7:31 PM Richard Palethorpe via ltp
> <ltp@lists.linux.it> wrote:
>>
>> Add an unstable kernel ABI flag and a runtest file for unstable
>> tests. This means we can add tests which are likely to be broken by
>> changes in the kernel ABI. Without disrupting LTP releases which are
>> required to be stable.
>>
>> Users who require stability can filter the tests with this flag
>> or not schedule the unstable runtest file(s).
>>
>> Signed-off-by: Richard Palethorpe <rpalethorpe@suse.com>
>> ---
>>
>> How about adding this to the fanotify22 patch?
>>
>> include/tst_test.h | 12 ++++++++++++
>> lib/tst_test.c | 6 ++++++
>> runtest/syscalls-unstable | 3 +++
>> 3 files changed, 21 insertions(+)
>> create mode 100644 runtest/syscalls-unstable
>>
>> diff --git a/include/tst_test.h b/include/tst_test.h
>> index 450ddf086..ff31e972e 100644
>> --- a/include/tst_test.h
>> +++ b/include/tst_test.h
>> @@ -174,6 +174,18 @@ struct tst_test {
>> int skip_in_lockdown:1;
>> int skip_in_compat:1;
>>
>> + /*
>> + * Test is for a feature that has not been added to the stable
>> + * kernel ABI. That is, it's for a feature only available in
>> + * linux-next, an RC or some other development branch.
>> + *
>> + * This string should be set to some text describing the
>> + * kernel branch and version the test was developed
>> + * against. e.g. "5.16 RC2", "linux-next-20211220",
>> + * "net-next".
>> + */
>> + const char *const unstable_abi_version;
>
> I'm not sure if this will bring convenience or trouble to LTP.
>
> If a new syscall is in development (or merged in linux-next) but
> drop/change in mainline-kernel. We have to adjust the test case
> accordingly.
If someone is motivated enough to contribute tests for an unreleased
feature. There is a high chance they will make the changes. In the worst
case we just delete the test.
>
> And after the feature is go into the mainline kernel finally, should
> we move that from 'syscalls-unstable' to 'syscalls' and remove the
> tst_test->unstable_abi_version field at the same time?
Yes.
>
> Btw, why not we just keep the unstable-syscall test case stay
> in the review phase until it gets merged in mailline-kernel?
> I guess that wouldn't block anything or make anyone unhappy.
It's a lot of work to merge patches into your own branch for testing RCs
and linux-next. It makes collaboration a lot harder. It's easy for
people just to enable the unstable tests. Then new features will get
tested on a much wider range of setups.
It increases the chances of finding bugs before release.
--
Thank you,
Richard.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2021-12-21 14:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20211220180748.36A90A3B8E@relay2.suse.de>
2021-12-21 11:30 ` [LTP] [RFC PATCH] API: Allow testing of kernel features in development Richard Palethorpe via ltp
2021-12-21 12:14 ` Li Wang
2021-12-21 13:56 ` Richard Palethorpe [this message]
2021-12-21 17:56 ` Petr Vorel
2021-12-22 8:41 ` Jan Stancek
2021-12-22 8:44 ` Richard Palethorpe
2021-12-22 9:29 ` Petr Vorel
2022-01-05 15:57 ` Cyril Hrubis
2022-01-05 16:00 ` Cyril Hrubis
2022-01-10 8:09 ` Richard Palethorpe
2022-01-28 12:32 ` Petr Vorel
2022-02-03 10:18 ` [LTP] [PATCH] Create policy for testing unstable kernel features Richard Palethorpe via ltp
2022-02-03 10:22 ` Petr Vorel
2022-02-04 7:46 ` Jan Stancek
2022-02-08 8:18 ` Li Wang
2022-03-03 13:33 ` Petr Vorel
2022-06-14 12:31 ` Petr Vorel
2022-06-14 13:13 ` Cyril Hrubis
2022-06-16 8:25 ` Petr Vorel
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=875yrif3qd.fsf@suse.de \
--to=rpalethorpe@suse.de \
--cc=liwang@redhat.com \
--cc=ltp@lists.linux.it \
/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