[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200623155419.GI9247@paulmck-ThinkPad-P72>
Date: Tue, 23 Jun 2020 08:54:19 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Akira Yokosawa <akiyks@...il.com>
Cc: linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
kernel-team@...com, mingo@...nel.org, stern@...land.harvard.edu,
parri.andrea@...il.com, will@...nel.org, peterz@...radead.org,
boqun.feng@...il.com, npiggin@...il.com, dhowells@...hat.com,
j.alglave@....ac.uk, luc.maranget@...ia.fr
Subject: Re: [PATCH tip/core/rcu 13/14] tools/memory-model/README: Expand
dependency of klitmus7
On Tue, Jun 23, 2020 at 11:37:32PM +0900, Akira Yokosawa wrote:
> On Mon, 22 Jun 2020 17:52:30 -0700, paulmck@...nel.org wrote:
> > From: Akira Yokosawa <akiyks@...il.com>
> >
> > klitmus7 is independent of the memory model but depends on the
> > build-target kernel release.
> > It occasionally lost compatibility due to kernel API changes [1, 2, 3].
> > It was remedied in a backwards-compatible manner respectively [4, 5, 6].
> >
> > Reflect this fact in README.
> >
> > [1]: b899a850431e ("compiler.h: Remove ACCESS_ONCE()")
> > [2]: 0bb95f80a38f ("Makefile: Globally enable VLA warning")
> > [3]: d56c0d45f0e2 ("proc: decouple proc from VFS with "struct proc_ops"")
> > [4]: https://github.com/herd/herdtools7/commit/e87d7f9287d1
> > ("klitmus: Use WRITE_ONCE and READ_ONCE in place of deprecated ACCESS_ONCE")
> > [5]: https://github.com/herd/herdtools7/commit/a0cbb10d02be
> > ("klitmus: Avoid variable length array")
> > [6]: https://github.com/herd/herdtools7/commit/46b9412d3a58
> > ("klitmus: Linux kernel v5.6.x compat")
> >
> > NOTE: [5] was ahead of herdtools7 7.53, which did not make an
> > official release. Code generated by klitmus7 without [5] can still be
> > built targeting Linux 4.20--5.5 if you don't care VLA warnings.
> >
> > Acked-by: Andrea Parri <parri.andrea@...il.com>
> > Signed-off-by: Akira Yokosawa <akiyks@...il.com>
> > Signed-off-by: Paul E. McKenney <paulmck@...nel.org>
> > ---
> > tools/memory-model/README | 30 ++++++++++++++++++++++++++++--
> > 1 file changed, 28 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/memory-model/README b/tools/memory-model/README
> > index b9c562e..90af203 100644
> > --- a/tools/memory-model/README
> > +++ b/tools/memory-model/README
> > @@ -28,8 +28,34 @@ downloaded separately:
> > See "herdtools7/INSTALL.md" for installation instructions.
> >
> > Note that although these tools usually provide backwards compatibility,
> > -this is not absolutely guaranteed. Therefore, if a later version does
> > -not work, please try using the exact version called out above.
> > +this is not absolutely guaranteed.
> > +
> > +For example, a future version of herd7 might not work with the model
> > +in this release. A compatible model will likely be made available in
> > +a later release of Linux kernel.
> > +
> > +If you absolutely need to run the model in this particular release,
> > +please try using the exact version called out above.
> > +
> > +klitmus7 is independent of the model provided here. It has its own
> > +dependency on a target kernel release where converted code is built
> > +and executed. Any change in kernel APIs essential to klitmus7 will
> > +necessitate an upgrade of klitmus7.
> > +
> > +If you find any compatibility issues in klitmus7, please inform the
> > +memory model maintainers.
> > +
> > +klitmus7 Compatibility Table
> > +----------------------------
> > +
> > + ============ ==========
> > + target Linux herdtools7
> > + ------------ ----------
> > + -- 4.18 7.48 --
> > + 4.15 -- 4.19 7.49 --
> > + 4.20 -- 5.5 7.54 --
> > + 5.6 -- HEAD
> > + ============ ==========
>
> Paul,
>
> I was planning to send an update on this one.
> herdtoolds7 7.56 will be released later this week (now tagged 7.56-rc1).
>
> Andrea tested klitmus7 7.56-rc1 against Linux 5.7 and 5.8-rc1.
> I tested it against Linux 5.7.4.
> klitmus7 worked fine in all these test.
>
> So I think we can safely update the bottom row of the table as:
>
> > + 5.6 -- 7.56 --
>
> Can you amend this one directly?
> Or do you want me to send a follow-up patch?
A follow-up patch is probably best. This can't be the only place that
must change? Or maybe we set this up better than I remember? ;-)
Thanx, Paul
Powered by blists - more mailing lists