[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1809041503470.17060-100000@netrider.rowland.org>
Date: Tue, 4 Sep 2018 15:09:49 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Andrea Parri <andrea.parri@...rulasolutions.com>
cc: Will Deacon <will.deacon@....com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
<linux-kernel@...r.kernel.org>, <linux-arch@...r.kernel.org>,
<mingo@...nel.org>, <peterz@...radead.org>, <boqun.feng@...il.com>,
<npiggin@...il.com>, <dhowells@...hat.com>, <j.alglave@....ac.uk>,
<luc.maranget@...ia.fr>, <akiyks@...il.com>
Subject: Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for
locks and remove it for ordinary release/acquire
On Tue, 4 Sep 2018, Andrea Parri wrote:
> Heh, your confusion might be the reflection of mine... ;-) That was
> indeed a long and not conclusive discussion (meaning there're pending
> issues); and I cannot claim to find "arguments" such as:
>
> "More than one kernel developer has expressed the opinion that
> the LKMM should enforce ordering of writes by locking."
>
> particularly helpful (I do tend to be convinced by arguments rather
> than by opinions). In fact, you can take the following as my only
> current "constructive argument" against the patch [1,2]:
>
> THE COMMIT MESSAGE IS RIDICULOUS; PLEASE EXPAND ON IT, AND DO
> SO BY LEVERAGING BOTH PROS AND CONS OF THE APPLIED CHANGES
Do you have any concrete suggestions (i.e., some actual text) for
improvements to the patch description? Earlier in your message you
mentioned that Will's comment:
LKMM offers stronger guarantees that can portably be relied upon
in the codebase.
would make a good addition. Suitably edited, it could be added to the
description. I can think of a few other things myself, but I'd like to
hear your thoughts. Anything else?
Alan
Powered by blists - more mailing lists