Received-SPF: pass (google.com: domain of linux-kernel+bounces-84239-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Tue, 27 Feb 2024 15:56:51 -0800
From: Dan Williams <dan.j.williams@intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>, 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>
Subject: Re: [PATCH 3/3] cxl/region: Use cond_guard() in show_targetN()
Message-ID: <65de76c3be2ad_1138c729419@dwillia2-xfh.jf.intel.com.notmuch>
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>
 <CAHk-=whYxkfLVtBW_B-PgNqhKOAThTbfoH5CxtOTkwOB6VOt6w@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAHk-=whYxkfLVtBW_B-PgNqhKOAThTbfoH5CxtOTkwOB6VOt6w@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ElibTby5ViOUJyYNZHYBr4Y8XutVK2ma3xhlYM7zkV+XX+BXvlFO/Ch7nK8V?=
 =?us-ascii?Q?fcZVbJtt8GAfJO9gj7wR8LOOqbdwJ8jW2A/cXg3bUw8q/YzzmN5loVr/KyvK?=
 =?us-ascii?Q?NPxWp9bRL+wcCSU6Pk4oxMaX23hxLY+qPV1qZ1ot3izxkraEPwIGuhAGK3/D?=
 =?us-ascii?Q?EFsaV+2HwwGcFyhUE9g8n+nbqE8L0mFo5itrz0TDwLGopOZHYAbI606iR2Ph?=
 =?us-ascii?Q?XHCrnELOw9akUO4/Oc4wkE2nsYtnRCk8kasnyr5/KA5U1Fvqiy05y5mldK/y?=
 =?us-ascii?Q?g2azozJ8gejQaWiNHavMg/08krSckeQom3kgCwnNyyva39A0F48fDA22inEF?=
 =?us-ascii?Q?/VXtreX6f+23ALw/JPNuXMxlJx8mhkCWPfIO4SRQ37FNTLhSzSzRFt+gl82p?=
 =?us-ascii?Q?fUrQ4IaiAPTxYPgnBIyyD+3PCaRIe493A2F9qaaBGkI6RoPnWWrZV90RMtZ8?=
 =?us-ascii?Q?ykllsI0Hve8oS1JBYNEmlIqbICBZaDl0c8l1c74KSTzYwYaH42/SbFxQN1OC?=
 =?us-ascii?Q?EVyEmMN0h7TZiog0DSB+80cLheYfCrsqkw+fL54pjC8ReFYrACtzch6HTEyM?=
 =?us-ascii?Q?PODT7GKprWZKyw7XlgdopsZz79Idl52Vs+QxwrdMDbEWsGOB1qQCXcbdbacx?=
 =?us-ascii?Q?olbF3qU3OSzKtGn+5RIsbv0oVRvNFrNfhf7Azq421Vme0mVbHcihvlC2006F?=
 =?us-ascii?Q?vB46PwN8u6WgDiOAdrXEf9Swq2/TWCMqBUwJ/qVDQtNiTFOlimdX0wbZEnr8?=
 =?us-ascii?Q?Vb38+66upN54JRyeD/ZT2h4bRXuT1fSwq87e0TVEzkwrbO10CeMn7rULGBae?=
 =?us-ascii?Q?n4GDz8ThQLpN30JyCJPaRuwZO0muuxXinaWb3sGE6wzhA9WyPDcbdWCOyk1c?=
 =?us-ascii?Q?PEWotf8YNHRVdEEzjacCgQDU/cOLVfk3YDbg/F47CpoZI57kdu7xHaI+y+jX?=
 =?us-ascii?Q?/Cwh3kPjuG8rQX2Mzzu+6Uu7AkeAV4nJ0hCJbuNMTxEpIQmQcv+EvHYejxeB?=
 =?us-ascii?Q?8F3xOEaARtrjfLGu5y1IDECPcNg+jvEAmVAIduFMh/GNUPlBrdc87SMpLOl7?=
 =?us-ascii?Q?Xm82Bpvp0pQJNBvYhss9XXuphCz8kTkj6P5svmKwqBm4cT1jd5GNBTLVIpuQ?=
 =?us-ascii?Q?+4RZFlUxuJKB2As+j7NB7L2ruwdjJAOpUnYY2cDsf4XL5UZNVS8fe3Pgt6Mo?=
 =?us-ascii?Q?oIdJ1TeT1eVANbYdF/6FThqQ92PZaiTVN61fS1Y+2SeW5lZ7bT92fOY8ELGp?=
 =?us-ascii?Q?CdP32DT1C/YExzulUF8o3/FKqZKddQbiUeaDMawTB7XeuP0117Hc45PyuyyF?=
 =?us-ascii?Q?7F4H+f+A4UDUnYXuXfXpVwvCoKwcdepVYUhXHIq1aQIxnOZnVNj5Fygkv3m4?=
 =?us-ascii?Q?OeN13v2+zngP7YP4gpQdP7reNdgH/OeCVzm6lTkJ/HTwFgQsw33Xd7bBle7k?=
 =?us-ascii?Q?vDzGGrXJVvMrEzTyfWWKGKhCN3ZACaymWD8X0ihUtbbYrzOhfqrUN8oJSuBV?=
 =?us-ascii?Q?6JUOF94uCROFGM296i/7iH8B/0bCaLfo+jlPldP/pvo+jHw28nDgIgTiLfMA?=
 =?us-ascii?Q?O7SuglvsiuL2Myv5KueMXilCVZ68ws6WIleW9WXbVKYfO5e/ikjc+JiHf39F?=
 =?us-ascii?Q?rg=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 069e275e-3ad1-454a-899a-08dc37efc5ff
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Feb 2024 23:56:53.9671
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 5oSA2KY05tjOukyY0/hh1E53YVSQDjgmEqjGBbefwIHHQostTficL50AEEkx+jlruRWGmfbqxEx0Ek3qcXeMnHg3OUk8CimFSGi+PByuMaw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR11MB8766
X-OriginatorOrg: intel.com

Linus Torvalds wrote:
> 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..

I appreciate that. It is difficult to judge what size clue bat to carry
from one thread to the next.

> 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).

This would have definitely saved me from thinking that passing a
"return" statement to a macro was an idea worth copying. I like that it
puts the onus on the caller to understand "this is a conditional" you
are responsible for handling the conditions, the macro is only handling
releasing the lock at the end of the scope".

> 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.

Ah, ok, yeah has been quiet on this thread for a while. I will take some
inspiration from this proposal and huddle again with Fabio.

Thanks for the nudge.