From: Cyril Hrubis <chrubis@suse.cz>
To: Petr Vorel <pvorel@suse.cz>
Cc: Yael Tzur <yaelt@google.com>,
linux-integrity@vger.kernel.org, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v4] syscalls/keyctl09: test encrypted keys with provided decrypted data.
Date: Thu, 3 Mar 2022 14:46:39 +0100 [thread overview]
Message-ID: <YiDGvzETiI/nxwW/@yuki> (raw)
In-Reply-To: <YiDB7wO3Se/vN15+@pevik>
Hi!
> > > > I this case I guess that in this case the change is so minimal that we
> > > > can add this test into LTP once it reaches Linus tree.
> > > Cyril, maybe we could finally merge our policy (waiting ack for you):
> > > https://patchwork.ozlabs.org/project/ltp/patch/20220203101803.10204-1-rpalethorpe@suse.com/
> > > and put keyctl09 into runtest/staging now.
>
> > I guess that we still did not agree on exactly how this should be
> > handled or did we?
>
> Isn't it enough "Once a feature is part of the stable kernel ABI the associated
> test must be moved out of staging." ?
The main problem is that someone has to make sure that it happens and
the process would be prone to errors. What I proposed instead was a flag
that would set a kernel version in which the ABI is going to be merged
and put the test right into the final runtest files. Then we can simply
skip the test on older kernels or do anything else we see as a
reasonable solution. At the same time we can easily add automatic
checker that would look for these flags in metadata into the CI which
would, for instance, send email to the ML once the flag is supposed to
be removed.
In this case it does not actually matter, since the test is guarded by a
kernel config option that is introduced by the patchset and the change
is fairly miniminal, so I do not think that there would be any changes
to the ABI anyways.
--
Cyril Hrubis
chrubis@suse.cz
next prev parent reply other threads:[~2022-03-03 13:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-23 20:07 [PATCH v4] syscalls/keyctl09: test encrypted keys with provided decrypted data Yael Tzur
2022-03-02 15:53 ` [LTP] " Cyril Hrubis
2022-03-02 20:16 ` Yael Tzur
2022-03-03 6:14 ` Petr Vorel
2022-03-03 12:44 ` Cyril Hrubis
2022-03-03 13:26 ` Petr Vorel
2022-03-03 13:46 ` Cyril Hrubis [this message]
2022-03-03 14:07 ` Petr Vorel
2022-03-16 20:10 ` Yael Tzur
2022-03-17 20:38 ` Petr Vorel
2022-03-23 19:13 ` Petr Vorel
2022-03-24 13:35 ` Cyril Hrubis
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=YiDGvzETiI/nxwW/@yuki \
--to=chrubis@suse.cz \
--cc=linux-integrity@vger.kernel.org \
--cc=ltp@lists.linux.it \
--cc=pvorel@suse.cz \
--cc=yaelt@google.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