From: Richard Palethorpe <rpalethorpe@suse.de>
To: Jan Stancek <jstancek@redhat.com>
Cc: LTP List <ltp@lists.linux.it>, automated-testing@lists.yoctoproject.org
Subject: Re: [LTP] [RFC PATCH] API: Allow testing of kernel features in development
Date: Wed, 22 Dec 2021 08:44:43 +0000 [thread overview]
Message-ID: <87wnjxdlrm.fsf@suse.de> (raw)
In-Reply-To: <CAASaF6zQK=w5+QzUGM8wfOLJNUHFKPJP5dE_XnQUaya5if3VMQ@mail.gmail.com>
Hello,
Jan Stancek <jstancek@redhat.com> writes:
> On Tue, Dec 21, 2021 at 6:56 PM Petr Vorel <pvorel@suse.cz> wrote:
>>
>> i all,
>>
>> [ Cc automated-testing and people who might be interested ]
>>
>> > 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).
>>
>> I'm ok for this from a long term perspective, because agree Richie it can help
>> people to run tests on kernel from next tree or mainline rc kernel).
>>
>> It's not much work to maintain this.
>>
>> It'd also help people writing tests for fanotify and IMA not having wait
>> several weeks.
>>
>> Yes, we could add it to fanotify22 [1], but not to ima_conditionals.sh [2],
>> which is shell. But adding support to shell is trivial.
>>
>> Acked-by: Petr Vorel <petr.vorel@gmail.com>
>>
>> ....
>> > +++ b/runtest/syscalls-unstable
>> How about having name syscalls-next? Although there can be tests which are from
>> some kernel maintainer tree (it does not have to be limited to next tree),
>> unstable can mean "tests which aren't fixed yet and thus buggy".
>
> staging?
Staging and unstable could equally mean the test itself is not fininshed
IMO. I didn't suggest next for exactly the reason mentioned, but it
might be the better choice.
>
> IMO separate runtest would be enough, any notes why and how test was developed
> could be in comments in code, where people can find it (less metadata
> to maintain),
> and those comments could stay there after feature is accepted to
> mainline, we just
> move test between runtest files.
Then the test has a useless or misleading comment saying it was
developed against a feature still in development. It's trivial to remove
such comments or meta-data. I expect test authors will do it themselves
and if they don't we can rethink accepting such tests.
Also the patch uses the meta-data to print a hint. That way we do not
need to look at the source code, runtest file and LTP version before
deciding on the severity of a problem. Doing extra work upstream saves a
lot of work downstream.
Finally note that the plan is to schedule tests without runtest files
for parallel execution. That requires meta-data.
>
>> > @@ -0,0 +1,3 @@
>> > +# Tests for kernel features which are not finalized
>> > +
>> > +fanotify22 fanotify22
>>
>> Kind regards,
>> Petr
>>
>> [1] https://patchwork.ozlabs.org/project/ltp/list/?series=272782
>> [2] https://patchwork.ozlabs.org/project/ltp/list/?series=265664
>>
>> --
>> Mailing list info: https://lists.linux.it/listinfo/ltp
>>
--
Thank you,
Richard.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2021-12-22 9:36 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
2021-12-21 17:56 ` Petr Vorel
2021-12-22 8:41 ` Jan Stancek
2021-12-22 8:44 ` Richard Palethorpe [this message]
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=87wnjxdlrm.fsf@suse.de \
--to=rpalethorpe@suse.de \
--cc=automated-testing@lists.yoctoproject.org \
--cc=jstancek@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