From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CCE2FC4332F for ; Mon, 12 Dec 2022 09:38:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231791AbiLLJiY convert rfc822-to-8bit (ORCPT ); Mon, 12 Dec 2022 04:38:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57414 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231565AbiLLJiU (ORCPT ); Mon, 12 Dec 2022 04:38:20 -0500 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.86.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A3B1C1D6 for ; Mon, 12 Dec 2022 01:38:18 -0800 (PST) Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-195-0YlasvZ9OcqH1RVoAzaIQQ-1; Mon, 12 Dec 2022 09:38:15 +0000 X-MC-Unique: 0YlasvZ9OcqH1RVoAzaIQQ-1 Received: from AcuMS.Aculab.com (10.202.163.6) by AcuMS.aculab.com (10.202.163.6) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Mon, 12 Dec 2022 09:38:12 +0000 Received: from AcuMS.Aculab.com ([::1]) by AcuMS.aculab.com ([::1]) with mapi id 15.00.1497.044; Mon, 12 Dec 2022 09:38:12 +0000 From: David Laight To: 'Andrzej Hajda' , "linux-kernel@vger.kernel.org" , "intel-gfx@lists.freedesktop.org" , "dri-devel@lists.freedesktop.org" CC: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , Andi Shyti , Andrew Morton , Andy Shevchenko , Arnd Bergmann Subject: RE: [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg Thread-Topic: [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg Thread-Index: AQHZC+X/n2yHksRnF0Csd/+tl8P8Ka5qAX6g Date: Mon, 12 Dec 2022 09:38:12 +0000 Message-ID: References: <20221209154843.4162814-1-andrzej.hajda@intel.com> In-Reply-To: <20221209154843.4162814-1-andrzej.hajda@intel.com> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Andrzej Hajda > Sent: 09 December 2022 15:49 > > The pattern of setting variable with new value and returning old > one is very common in kernel. Usually atomicity of the operation > is not required, so xchg seems to be suboptimal and confusing in > such cases. Since name xchg is already in use and __xchg is used > in architecture code, proposition is to name the macro exchange. Dunno, if it is non-atomic then two separate assignment statements is decidedly more obvious and needs less brain cells to process. Otherwise someone will assume 'something clever' is going on and the operation is atomic. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)