Received: by 2002:a05:7412:37c9:b0:e2:908c:2ebd with SMTP id jz9csp1918734rdb; Thu, 21 Sep 2023 03:37:21 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGCzJ1E0ZIi61AzzZlJ1RuqfcS0xA1UmRq1dUkEmXmBfOkakqXICVNqxtkHFJ1tqmxuGwze X-Received: by 2002:a05:6358:2495:b0:143:5fd5:b826 with SMTP id m21-20020a056358249500b001435fd5b826mr5489834rwc.24.1695292641528; Thu, 21 Sep 2023 03:37:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695292641; cv=none; d=google.com; s=arc-20160816; b=cpQBU8140k9i8t+Kim7uNanoz8TSwqFPe7BY/WCQRzDfx0P8DGcRTpQX0cxBaAF/2P 5JJoyo2znon0TXFGrXAG3+Sicsn7Okx39D/X52ZLYH7YYtHuP29r3N+O20jHvRLcQbc1 6IwlCeBzL4yYWHK/D9pM9ln1fzi8cwuC27R+OlTj47RWYRZn7lIzTq4OyWNjIxroSwHT eHEWjgPv73EI+4E5CVsdr9HyHnnJXFLz7COQbKO2E/PTXrtbcT+B1fj2JppFjK7J/9EH Y18hjEcLmtfBPSKt5k0nYlPZllUd+6ROKLP3STRbtEAtbhbKA2BKmvAcxUq0FPKe6f+j 8tFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=HhvtpludUjIr++HnR2WYgKkCmY0kr0ew9GoO5GG10A0=; fh=HWoutUjeO3vBNMEmPrQm/EUZFGQCi9521kQTggTMSMY=; b=TsoWugKZQSyXHOKeY827svB1vM3edr9Gk+Fma43YGl3DfbXGneiP4WPZYSrYqfoMp6 ID4euYkrn730eqpYzgfvnn4gFNQAMPhXsigCWgokO31EB0F/GTD8omVmXCwOcTotKyjC /c9ijUaztsLIkHYiMz/KsBC4b3Urc0+FS9tdqMnQ9xjzVi6lJ1ldimanxOxL0wlzYhmH jzQgPel0bIiMNgDlLJhuw8Tic5VsZ2vRITLzbQdP8QT4Xy3zbRAfE5tSLRh5uht1ePa0 pTMsCCzd9vND23KT7PPrQhK8/LOxo9UvFfUhpfHhy98pFnnVZ/c6Pq+KoYDz+9mJLhH9 QGKA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=B1245b9t; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Return-Path: Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id g22-20020a056a001a1600b00690c94b4cd1si1223094pfv.291.2023.09.21.03.37.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Sep 2023 03:37:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=B1245b9t; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 626EF826FAEB; Wed, 20 Sep 2023 00:58:27 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233678AbjITH6X (ORCPT + 99 others); Wed, 20 Sep 2023 03:58:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42658 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233781AbjITH6U (ORCPT ); Wed, 20 Sep 2023 03:58:20 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E1CDCE4; Wed, 20 Sep 2023 00:58:11 -0700 (PDT) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 7540622696; Wed, 20 Sep 2023 07:58:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1695196690; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=HhvtpludUjIr++HnR2WYgKkCmY0kr0ew9GoO5GG10A0=; b=B1245b9ttuxgIdWWprtAfA6rU3+OR02SOASLM7wuOEHHj8rhAtO8CoZ56Als8UKJBM+TWR MO6hVGOSCz7bvFS/nq55lAth6ketQI/xF3e3pNfUEssmMNKyIe2N/pVy1PDBoCJqKbFBY4 xR3O3LKETqdt52j5zmEq1faOygbg3K8= Received: from suse.cz (pmladek.tcp.ovpn2.prg.suse.de [10.100.208.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 3800D2C142; Wed, 20 Sep 2023 07:58:10 +0000 (UTC) Date: Wed, 20 Sep 2023 09:58:09 +0200 From: Petr Mladek To: Thomas Gleixner Cc: John Ogness , Greg Kroah-Hartman , Jiri Slaby , linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Zijlstra Subject: Re: [PATCH tty v1 01/74] serial: core: Provide port lock wrappers Message-ID: References: <20230914183831.587273-1-john.ogness@linutronix.de> <20230914183831.587273-2-john.ogness@linutronix.de> <87msxiuekv.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87msxiuekv.ffs@tglx> X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Wed, 20 Sep 2023 00:58:27 -0700 (PDT) Adding Peter into Cc who also has a big experience with locking APIs. Well, I think that he would not care ;-) On Tue 2023-09-19 21:51:12, Thomas Gleixner wrote: > On Tue, Sep 19 2023 at 16:24, Petr Mladek wrote: > > On Thu 2023-09-14 20:43:18, John Ogness wrote: > > IMHO, it would have been better to pass the flags variable directly > > via a macro as it is done in most *_lock_*_irqsafe() APIs. I mean > > something like: > > > > /** > > * uart_port_trylock_irqsave - Try to lock the UART port, save and disable interrupts > > * @up: Pointer to UART port structure > > * @flags: Interrupt flags storage > > * > > * Returns: True if lock was acquired, false otherwise > > */ > > #define uart_port_lock_irqsave(up, flags) \ > > ({ \ > > local_irq_save(flags); \ > > uart_port_lock(lock) \ > > }) > > It's worse. > > 1) Macros are not type safe by themself and rely on type safety > of the inner workings. > > 2) Macros are bad for grep as you can't search for a 'struct foo *' > argument. Even semantic parsers have their problems with macro > constructs. I just learned that again when doing this. > > 3) Macros are just horrible to read > > 4) If you want to out of line the wrapper later, then you still > have to keep the macro around because the 'flags' argument is by > value and not a pointer. > > >From a code generation point of view it's completely irrelevant whether > you have a macro or an inline. That was different 25 years ago, but who > cares about museum compilers today. I probably was not clear enough. The difference and the motivation is to pass the "flags" variable instead of pointer "*flags". Both most common APIs, local_irq_save(flags) and spin_lock_irqsave(lock, flags) pass the variable. Also most subsystem specific wrappers do so. IMHO, some consistency makes the life easier for developers, especially for frequently used API. And the patchset seems to be adding >350 users of the uart_port_lock_*irqsave() API. I do not know. Maybe using macros was bad decision for local_irq*() and spin_lock*() API. Anyway, we are going to live with the uart_port_lock*() API for a looong time. And I want to be sure that we do not create (small) headaches for future generations. OK, maybe this particular difference is not important enough. As I said, I do not resist on the change. Best Regards, Petr