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 X-Spam-Level: X-Spam-Status: No, score=-8.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0756CC433DB for ; Wed, 17 Feb 2021 17:14:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D3E9364E4B for ; Wed, 17 Feb 2021 17:14:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234376AbhBQROD convert rfc822-to-8bit (ORCPT ); Wed, 17 Feb 2021 12:14:03 -0500 Received: from mga17.intel.com ([192.55.52.151]:45679 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234282AbhBQRN4 (ORCPT ); Wed, 17 Feb 2021 12:13:56 -0500 IronPort-SDR: z8BdrBP6bYVx8VlJ2jZJeqIr0/rzfudMnbD9SsM8tOv7u9tRv69azkwhyRD6iTSTI9pU1te0bX kuZ22rS0d4AQ== X-IronPort-AV: E=McAfee;i="6000,8403,9898"; a="163039261" X-IronPort-AV: E=Sophos;i="5.81,184,1610438400"; d="scan'208";a="163039261" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Feb 2021 09:13:15 -0800 IronPort-SDR: Ze8hAK6HItV4g6zHQhfupFSfrmcGUQEuGy1aaFVF31i+EmsF3J0xduCKFOkGcaCBGcbbCMTpVW M10pDqE4dSAQ== X-IronPort-AV: E=Sophos;i="5.81,184,1610438400"; d="scan'208";a="400034792" Received: from mvalka-mobl1.ger.corp.intel.com (HELO localhost) ([10.252.39.140]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Feb 2021 09:13:06 -0800 From: Jani Nikula To: Petr Mladek , Andy Shevchenko Cc: Christian =?utf-8?Q?K=C3=B6nig?= , Sakari Ailus , Rasmus Villemoes , Sergey Senozhatsky , Steven Rostedt , Andy Shevchenko , Alex Deucher , Mikita Lipski , Eryk Brol , Chris Wilson , "David S. Miller" , Rahul Lakkireddy , Francis Laniel , amd-gfx@lists.freedesktop.org, dri-devel , Linux Kernel Mailing List , intel-gfx , netdev , Harry Wentland , Leo Li , David Airlie , Daniel Vetter , Joonas Lahtinen , Rodrigo Vivi , Raju Rangoju , Jakub Kicinski Subject: Re: [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20210215142137.64476-1-andriy.shevchenko@linux.intel.com> <43456ba7-c372-84cc-4949-dcb817188e21@amd.com> Date: Wed, 17 Feb 2021 19:13:03 +0200 Message-ID: <8735xubotc.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 17 Feb 2021, Petr Mladek wrote: > On Mon 2021-02-15 16:39:26, Andy Shevchenko wrote: >> +Cc: Sakari and printk people >> >> On Mon, Feb 15, 2021 at 4:28 PM Christian König >> wrote: >> > Am 15.02.21 um 15:21 schrieb Andy Shevchenko: >> > > We have already few similar implementation and a lot of code that can benefit >> > > of the yesno() helper. Consolidate yesno() helpers under string.h hood. >> > > >> > > Signed-off-by: Andy Shevchenko >> > >> > Looks like a good idea to me, feel free to add an Acked-by: Christian >> > König to the series. >> >> Thanks. >> >> > But looking at the use cases for this, wouldn't it make more sense to >> > teach kprintf some new format modifier for this? >> >> As a next step? IIRC Sakari has at some point the series converted >> yesno and Co. to something which I don't remember the details of. >> >> Guys, what do you think? > > Honestly, I think that yesno() is much easier to understand than %py. > And %py[DOY] looks really scary. It has been suggested at > https://lore.kernel.org/lkml/YCqaNnr7ynRydczE@smile.fi.intel.com/#t > > Yes, enabledisable() is hard to parse but it is still self-explaining > and can be found easily by cscope. On the contrary, %pyD will likely > print some python code and it is not clear if it would be compatible > with v3. I am just kidding but you get the picture. Personally I prefer %s and the functions. I think the format specifiers have become unwieldy. I don't remember any of the kernel specific ones by heart, I always look them up or just cargo-cult. I think the fourcc format specifiers are a nice cleanup, but I don't remember them either. I'd like something like %foo{yesno} where, if you remember the %foo part, you could actually also remember the rest. But really if you get *any* version accepted, I'm not going to argue against it, and you can disregard this as meaningless bikeshedding. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center