Received-SPF: pass (google.com: domain of linux-kernel+bounces-84131-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <170905252721.2268463.6714121678946763402.stgit@dwillia2-xfh.jf.intel.com>
 <170905254443.2268463.935306988251313983.stgit@dwillia2-xfh.jf.intel.com>
 <CAHk-=whBVhnh=KSeBBRet=E7qJAwnPR_aj5em187Q3FiD+LXnA@mail.gmail.com> <65de5725824ba_1138c72948c@dwillia2-xfh.jf.intel.com.notmuch>
In-Reply-To: <65de5725824ba_1138c72948c@dwillia2-xfh.jf.intel.com.notmuch>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 27 Feb 2024 14:34:52 -0800
Message-ID: <CAHk-=whYxkfLVtBW_B-PgNqhKOAThTbfoH5CxtOTkwOB6VOt6w@mail.gmail.com>
Subject: Re: [PATCH 3/3] cxl/region: Use cond_guard() in show_targetN()
To: Dan Williams <dan.j.williams@intel.com>
Cc: peterz@infradead.org, gregkh@linuxfoundation.org, 
	Ira Weiny <ira.weiny@intel.com>, Dave Jiang <dave.jiang@intel.com>, 
	Jonathan Cameron <Jonathan.Cameron@huawei.com>, 
	"Fabio M. De Francesco" <fabio.maria.de.francesco@linux.intel.com>, linux-kernel@vger.kernel.org, 
	linux-cxl@vger.kernel.org
Content-Type: multipart/mixed; boundary="00000000000083e343061264a3e1"

--00000000000083e343061264a3e1
Content-Type: text/plain; charset="UTF-8"

On Tue, 27 Feb 2024 at 13:42, Dan Williams <dan.j.williams@intel.com> wrote:
>
> I will also note that these last 3 statements, nuking the proposal from
> space, I find excessive. Yes, on the internet no one can hear you being
> subtle, but the "MORE READABLE" and "NOTHING" were pretty darn
> unequivocal, especially coming from the person who has absolute final
> say on what enters his project.

Heh. It's not just " one can hear you being subtle", sometimes it's
also "people don't take hints". It can be hard to tell..

Anyway, it's not that I hate the guard things in general. But I do
think they need to be used carefully, and I do think it's very
important that they have clean interfaces.

The current setup came about after quite long discussions about
getting reasonable syntax, and I'm still a bit worried even about the
current simpler ones.

And by "simpler ones" I don't mean our current scoped_cond_guard()
thing. We have exactly one user of it, and I have considered getting
rid of that one user because I think it's absolutely horrid. I haven't
figured out a better syntax for it.

For the non-scoped version, I actually think there *would* be a better
syntax - putting the error case after the macro (the way we put the
success case after the macro for the scoped one).

In fact, maybe the solution is to make the scoped and non-scoped
versions act very similar: we could do something like this:

        [scoped_]cond_guard(name, args) { success } else { fail };

and that syntax feels much more C-line to me.

So maybe something like the attached (TOTALLY UNTESTED!!) patch for
the scoped version, and then the non-scoped version would have the
same syntax (except it would have to generate that __UNIQUE_ID()
thing, of course).

I haven't thought much about this. But I think this would be more
acceptable to me, and also solve some of the ugliness with the current
pre-existing scoped_cond_guard().

I dunno. PeterZ did the existing stuff, but he's offlined due to
shoulder problems so not likely to chip in.

              Linus

--00000000000083e343061264a3e1
Content-Type: text/x-patch; charset="US-ASCII"; name="patch.diff"
Content-Disposition: attachment; filename="patch.diff"
Content-Transfer-Encoding: base64
Content-ID: <f_lt4y3wa90>
X-Attachment-Id: f_lt4y3wa90

IGluY2x1ZGUvbGludXgvY2xlYW51cC5oIHwgNyArKystLS0tCiBrZXJuZWwvcHRyYWNlLmMgICAg
ICAgICB8IDUgKysrLS0KIDIgZmlsZXMgY2hhbmdlZCwgNiBpbnNlcnRpb25zKCspLCA2IGRlbGV0
aW9ucygtKQoKZGlmZiAtLWdpdCBhL2luY2x1ZGUvbGludXgvY2xlYW51cC5oIGIvaW5jbHVkZS9s
aW51eC9jbGVhbnVwLmgKaW5kZXggYzJkMDliYzRmOTc2Li5hMDE1YWM5NTE3YTYgMTAwNjQ0Ci0t
LSBhL2luY2x1ZGUvbGludXgvY2xlYW51cC5oCisrKyBiL2luY2x1ZGUvbGludXgvY2xlYW51cC5o
CkBAIC0xNDIsNyArMTQyLDcgQEAgc3RhdGljIGlubGluZSBjbGFzc18jI19uYW1lIyNfdCBjbGFz
c18jI19uYW1lIyNleHQjI19jb25zdHJ1Y3RvcihfaW5pdF9hcmdzKSBcCiAgKglmb3IgY29uZGl0
aW9uYWwgbG9ja3MgdGhlIGxvb3AgYm9keSBpcyBza2lwcGVkIHdoZW4gdGhlIGxvY2sgaXMgbm90
CiAgKglhY3F1aXJlZC4KICAqCi0gKiBzY29wZWRfY29uZF9ndWFyZCAobmFtZSwgZmFpbCwgYXJn
cy4uLikgeyB9OgorICogc2NvcGVkX2NvbmRfZ3VhcmQgKG5hbWUsIGFyZ3MuLi4pIHsgfSBbIGVs
c2UgeyBmYWlsIH0gOgogICogICAgICBzaW1pbGFyIHRvIHNjb3BlZF9ndWFyZCgpLCBleGNlcHQg
aXQgZG9lcyBmYWlsIHdoZW4gdGhlIGxvY2sKICAqICAgICAgYWNxdWlyZSBmYWlscy4KICAqCkBA
IC0xNjksMTEgKzE2OSwxMCBAQCBzdGF0aWMgaW5saW5lIGNsYXNzXyMjX25hbWUjI190IGNsYXNz
XyMjX25hbWUjI2V4dCMjX2NvbnN0cnVjdG9yKF9pbml0X2FyZ3MpIFwKIAlmb3IgKENMQVNTKF9u
YW1lLCBzY29wZSkoYXJncyksCQkJCQlcCiAJICAgICAqZG9uZSA9IE5VTEw7IF9fZ3VhcmRfcHRy
KF9uYW1lKSgmc2NvcGUpICYmICFkb25lOyBkb25lID0gKHZvaWQgKikxKQogCi0jZGVmaW5lIHNj
b3BlZF9jb25kX2d1YXJkKF9uYW1lLCBfZmFpbCwgYXJncy4uLikgXAorI2RlZmluZSBzY29wZWRf
Y29uZF9ndWFyZChfbmFtZSwgYXJncy4uLikgXAogCWZvciAoQ0xBU1MoX25hbWUsIHNjb3BlKShh
cmdzKSwgXAogCSAgICAgKmRvbmUgPSBOVUxMOyAhZG9uZTsgZG9uZSA9ICh2b2lkICopMSkgXAot
CQlpZiAoIV9fZ3VhcmRfcHRyKF9uYW1lKSgmc2NvcGUpKSBfZmFpbDsgXAotCQllbHNlCisJCWlm
IChfX2d1YXJkX3B0cihfbmFtZSkoJnNjb3BlKSkKIAogLyoKICAqIEFkZGl0aW9uYWwgaGVscGVy
IG1hY3JvcyBmb3IgZ2VuZXJhdGluZyBsb2NrIGd1YXJkcyB3aXRoIHR5cGVzLCBlaXRoZXIgZm9y
CmRpZmYgLS1naXQgYS9rZXJuZWwvcHRyYWNlLmMgYi9rZXJuZWwvcHRyYWNlLmMKaW5kZXggMmZh
YmQ0OTdkNjU5Li5mNTA5YjIxYTU3MTEgMTAwNjQ0Ci0tLSBhL2tlcm5lbC9wdHJhY2UuYworKysg
Yi9rZXJuZWwvcHRyYWNlLmMKQEAgLTQ0MSw4ICs0NDEsNyBAQCBzdGF0aWMgaW50IHB0cmFjZV9h
dHRhY2goc3RydWN0IHRhc2tfc3RydWN0ICp0YXNrLCBsb25nIHJlcXVlc3QsCiAJICogU1VJRCwg
U0dJRCBhbmQgTFNNIGNyZWRzIGdldCBkZXRlcm1pbmVkIGRpZmZlcmVudGx5CiAJICogdW5kZXIg
cHRyYWNlLgogCSAqLwotCXNjb3BlZF9jb25kX2d1YXJkIChtdXRleF9pbnRyLCByZXR1cm4gLUVS
RVNUQVJUTk9JTlRSLAotCQkJICAgJnRhc2stPnNpZ25hbC0+Y3JlZF9ndWFyZF9tdXRleCkgewor
CXNjb3BlZF9jb25kX2d1YXJkIChtdXRleF9pbnRyLCAmdGFzay0+c2lnbmFsLT5jcmVkX2d1YXJk
X211dGV4KSB7CiAKIAkJc2NvcGVkX2d1YXJkICh0YXNrX2xvY2ssIHRhc2spIHsKIAkJCXJldHZh
bCA9IF9fcHRyYWNlX21heV9hY2Nlc3ModGFzaywgUFRSQUNFX01PREVfQVRUQUNIX1JFQUxDUkVE
Uyk7CkBAIC00NjYsNiArNDY1LDggQEAgc3RhdGljIGludCBwdHJhY2VfYXR0YWNoKHN0cnVjdCB0
YXNrX3N0cnVjdCAqdGFzaywgbG9uZyByZXF1ZXN0LAogCiAJCQlwdHJhY2Vfc2V0X3N0b3BwZWQo
dGFzayk7CiAJCX0KKwl9IGVsc2UgeworCQlyZXR1cm4gLUVSRVNUQVJUTk9JTlRSOwogCX0KIAog
CS8qCg==
--00000000000083e343061264a3e1--