Date: Wed, 26 Jul 2017 20:47:50 +0800
From: Boqun Feng <boqun.feng@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will.deacon@arm.com>,
        Paul McKenney <paulmck@linux.vnet.ibm.com>,
        linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [RFC][PATCH v3]: documentation,atomic: Add new documents
Message-ID: <20170726124750.vktrn5zi2gmpzfru@tardis>
References: <20170609092450.jwmldgtli57ozxgq@hirez.programming.kicks-ass.net>
 <20170609154442.GB9236@arm.com>
 <20170609193604.ncw3hhgvewzc3h5u@hirez.programming.kicks-ass.net>
 <20170611135632.sl72klbeklelupej@tardis>
 <20170612144929.3wiwtbqopsfpm3qk@hirez.programming.kicks-ass.net>
 <20170726115328.2sxiitivlnlq64dk@hirez.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="6rrawpu6roqr6giv"
Content-Disposition: inline
In-Reply-To: <20170726115328.2sxiitivlnlq64dk@hirez.programming.kicks-ass.net>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2802
Lines: 96


--6rrawpu6roqr6giv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 26, 2017 at 01:53:28PM +0200, Peter Zijlstra wrote:
>=20
> New version..
>=20
>=20
> ---
> Subject: documentation,atomic: Add new documents
> From: Peter Zijlstra <peterz@infradead.org>
> Date: Mon Jun 12 14:50:27 CEST 2017
>=20
> Since we've vastly expanded the atomic_t interface in recent years the
> existing documentation is woefully out of date and people seem to get
> confused a bit.
>=20
> Start a new document to hopefully better explain the current state of
> affairs.
>=20
> The old atomic_ops.txt also covers bitmaps and a few more details so
> this is not a full replacement and we'll therefore keep that document
> around until such a time that we've managed to write more text to cover
> its entire.
>=20

You seems have a unfinished paragraph..

> Also please, ReST people, go away.
>=20
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
[...]
> +
> +Further, while something like:
> +
> +  smp_mb__before_atomic();
> +  atomic_dec(&X);
> +
> +is a 'typical' RELEASE pattern, the barrier is strictly stronger than
> +a RELEASE. Similarly for something like:
> +

=2E. at here. Maybe you planned to put stronger ACQUIRE pattern?

> +
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -498,7 +498,7 @@ VARIETIES OF MEMORY BARRIER
>       This means that ACQUIRE acts as a minimal "acquire" operation and
>       RELEASE acts as a minimal "release" operation.
> =20
[...]
> -
> -[!] Note that special memory barrier primitives are available for these
> -situations because on some CPUs the atomic instructions used imply full =
memory
> -barriers, and so barrier instructions are superfluous in conjunction wit=
h them,
> -and in such cases the special barrier primitives will be no-ops.
> -
> -See Documentation/core-api/atomic_ops.rst for more information.
> +See Documentation/atomic_t.txt for more information.
> =20

s/atomic_t.txt/atomic_{t,bitops}.txt/ ?

other than those two tiny things,

Reviewed-by: Boqun Feng <boqun.feng@gmail.com>

Regards,
Boqun

> =20
>  ACCESSING DEVICES

--6rrawpu6roqr6giv
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEj5IosQTPz8XU1wRHSXnow7UH+rgFAll4j3IACgkQSXnow7UH
+rg0RggAggBv0RkXZq2JlP9XGqAsIUWRz4TyQ93ovGNbcnumUqokIAtNUcbae7BP
d76NFMrt7w3U8mMolQjildIBqxO4975FYehvpuvHmSUNNIOsnoBJ+9Y3AtrTnBFQ
ecAQnRZ5rmDvyifPu6PI0QyG4PAK88+p+Gwj/ZudFUD8M7jIL4vNJvwlkxchywZO
WB4cAK4yvBJgZIz0H1AdbN/S4ZpHBmGq9Dbkx2uEu9VSfbnZA1Wp3fFbNtacEht4
1oI/7oTISjd7H8tJ6xRbb/lBEoc2j0viP2i8xTdB5jWXltbdjdVhRyKwb9b2oaNU
4RcoJNj5I5wbbzUdx6GaotAFD26I1Q==
=3aTA
-----END PGP SIGNATURE-----

--6rrawpu6roqr6giv--