Message ID | 20230411102454.85898-1-andriy.shevchenko@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2474316vqo; Tue, 11 Apr 2023 03:44:52 -0700 (PDT) X-Google-Smtp-Source: AKy350aYvewq92KNDn/FOeIyqotC2I3DPmXMQUCNztLp1JjMNjIqDQIdbInzuLK5/sphBj1sZh10 X-Received: by 2002:a62:5f84:0:b0:638:dc83:2048 with SMTP id t126-20020a625f84000000b00638dc832048mr1967406pfb.27.1681209892366; Tue, 11 Apr 2023 03:44:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681209892; cv=none; d=google.com; s=arc-20160816; b=wTQnWzMReFHxrGULFqX3z7VFKqob4aPZa4fU7XZDP5P9oMxQ1ZpdpEZgOgsU/tA8dC RW0kMguPDFWu/5Sm0ItfqJCf94w4z9Yf/uL8x7cOdEmVr06KhsihImojk0xRhuWt8vAm zbmZ8gu8hlKKDa/ktpmYdlEfJ5tViQQqhX6DEmNMUlf0oNu+AMkMbg18qLMHvat4DNal cf/OPfrZGQvi6LbJclmc697kZ2JK8BCzlzkJDMy4KM1rCq0h6erDZPAURbcKxkJie2P6 8SpazewVMS0u3vRRgNzpZz7QPRp23zdgLh15AbcuOACd7sydYHvr6xd6TchPRrJP0u78 blvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=z152FjkhHr7+T/uWvc/AiA1i2aTt4AGq5WJpjihd88Q=; b=wqe6XD6IBp5jQxiRuAGNWmbHkcSWZBfiYO7UDfzvHwrkBNFV99fTZ7nHH0sZftjpmk 3sNNulcsI8SPW0wpVUSFKAvDf55tSJdHyCY2GVYn7D2SKSojc48adLdo6i0wBHPx5UMM wAdkU4tbEBWHL9SP9hO8R88tjgCKV16kW4R6BCWOGAhs2kw41LpoYxjEXLkEso/HGh6e dF8qE3kuWlXvIWLuKodNnGRoZ7U/NrGAS5gavyf8kbhR18oc0Nb8WkCtbneh4Js+4B9a EJ5WD2Pmnc/JpfhFti6l23I/d5L8yCnfhGJAkSZwqugamyMjHrlwuozH85oRtKHEyuTx nzOA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=lF72DOyY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p30-20020a63741e000000b0051910c2b835si6942939pgc.91.2023.04.11.03.44.39; Tue, 11 Apr 2023 03:44:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=lF72DOyY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229638AbjDKKY6 (ORCPT <rfc822;leviz.kernel.dev@gmail.com> + 99 others); Tue, 11 Apr 2023 06:24:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51358 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229504AbjDKKY5 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 11 Apr 2023 06:24:57 -0400 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 80264121 for <linux-kernel@vger.kernel.org>; Tue, 11 Apr 2023 03:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1681208696; x=1712744696; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=gIQa0UBc6rrUYtPkGDZ1t1xT6zplGxALb8OYgbohTeo=; b=lF72DOyYlU6IZRgiW2Kf5dnwCpMZXAn8zB3GV5D+P/AuUcnaIdUauUcO RJddbYVMLqBIq04jQ0fa/q/mpOTpA7ICoGp11RfBDCNm/gKvHkVBXjtTU km1y8RmDwDxYcJPU9Z2THvFIBEhsQrZdEPCGo/AtjrF76aWWreYhhShBK BJiZPQAeHQhs9m7HnJlayudlQ1d2uK0cX6QOoSYiUqdYoiV48a/bLQ4Ie /8My0iIg6WvDRkx4KK+iNyXwWHyztclrlJ1TDDaGO3znxKxBHV6WaRTmA hUhATYCxonoVjeJCWqDxDzm4fjHQ+4LNIg5lvlZN/kmwma0fSg77aYXk0 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10676"; a="343585780" X-IronPort-AV: E=Sophos;i="5.98,336,1673942400"; d="scan'208";a="343585780" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Apr 2023 03:24:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10676"; a="812517038" X-IronPort-AV: E=Sophos;i="5.98,336,1673942400"; d="scan'208";a="812517038" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga004.jf.intel.com with ESMTP; 11 Apr 2023 03:24:54 -0700 Received: by black.fi.intel.com (Postfix, from userid 1003) id 6D26614B; Tue, 11 Apr 2023 13:24:57 +0300 (EEST) From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>, linux-kernel@vger.kernel.org Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>, Andrew Morton <akpm@linux-foundation.org> Subject: [PATCH v1 1/1] kernel.h: Split out COUNT_ARGS() and CONCATENATE() Date: Tue, 11 Apr 2023 13:24:54 +0300 Message-Id: <20230411102454.85898-1-andriy.shevchenko@linux.intel.com> X-Mailer: git-send-email 2.40.0.1.gaa8946217a0b MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.4 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762876343671489683?= X-GMAIL-MSGID: =?utf-8?q?1762876343671489683?= |
Series |
[v1,1/1] kernel.h: Split out COUNT_ARGS() and CONCATENATE()
|
|
Commit Message
Andy Shevchenko
April 11, 2023, 10:24 a.m. UTC
kernel.h is being used as a dump for all kinds of stuff for a long time.
The COUNT_ARGS() and CONCATENATE() macros may be used in some places
without need of the full kernel.h dependency train with it.
Here is the attempt on cleaning it up by splitting out these macros().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
include/linux/args.h | 13 +++++++++++++
include/linux/kernel.h | 8 +-------
2 files changed, 14 insertions(+), 7 deletions(-)
create mode 100644 include/linux/args.h
Comments
On Tue, 11 Apr 2023 13:24:54 +0300 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > kernel.h is being used as a dump for all kinds of stuff for a long time. > The COUNT_ARGS() and CONCATENATE() macros may be used in some places > without need of the full kernel.h dependency train with it. > > Here is the attempt on cleaning it up by splitting out these macros(). > > --- a/include/linux/kernel.h > +++ b/include/linux/kernel.h > @@ -13,6 +13,7 @@ > > #include <linux/stdarg.h> > #include <linux/align.h> > +#include <linux/args.h> A more energetic patch would have included args.h into each file which calls COUNT_ARGS() and CONCATENATE(), and not included args.h into kernel.h. And that appears to be very easy - only bpf uses these things? In fact these macros are so weird and ugly I'd be inclined to move them into some bpf header so we don't have to see them again. No args.h, which might avoid encouraging others to use them.
On Tue, Apr 11, 2023 at 03:21:19PM -0700, Andrew Morton wrote: > On Tue, 11 Apr 2023 13:24:54 +0300 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > > kernel.h is being used as a dump for all kinds of stuff for a long time. > > The COUNT_ARGS() and CONCATENATE() macros may be used in some places > > without need of the full kernel.h dependency train with it. > > > > Here is the attempt on cleaning it up by splitting out these macros(). > > > > --- a/include/linux/kernel.h > > +++ b/include/linux/kernel.h > > @@ -13,6 +13,7 @@ > > > > #include <linux/stdarg.h> > > #include <linux/align.h> > > +#include <linux/args.h> > > A more energetic patch would have included args.h into each file which > calls COUNT_ARGS() and CONCATENATE(), and not included args.h into > kernel.h. And that appears to be very easy - only bpf uses these things? > > In fact these macros are so weird and ugly I'd be inclined to move them > into some bpf header so we don't have to see them again. No > args.h, which might avoid encouraging others to use them. We have more users than one and a couple of users that reimplement this macro under different names.
On Wed, 12 Apr 2023 15:56:43 +0300 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > On Tue, Apr 11, 2023 at 03:21:19PM -0700, Andrew Morton wrote: > > On Tue, 11 Apr 2023 13:24:54 +0300 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > > > > kernel.h is being used as a dump for all kinds of stuff for a long time. > > > The COUNT_ARGS() and CONCATENATE() macros may be used in some places > > > without need of the full kernel.h dependency train with it. > > > > > > Here is the attempt on cleaning it up by splitting out these macros(). > > > > > > --- a/include/linux/kernel.h > > > +++ b/include/linux/kernel.h > > > @@ -13,6 +13,7 @@ > > > > > > #include <linux/stdarg.h> > > > #include <linux/align.h> > > > +#include <linux/args.h> > > > > A more energetic patch would have included args.h into each file which > > calls COUNT_ARGS() and CONCATENATE(), and not included args.h into > > kernel.h. And that appears to be very easy - only bpf uses these things? > > > > In fact these macros are so weird and ugly I'd be inclined to move them > > into some bpf header so we don't have to see them again. No > > args.h, which might avoid encouraging others to use them. > > We have more users than one I cant find any? > and a couple of users that reimplement this macro > under different names. Where are these? What the heck does it do and why is it so ugly and why isn't it documented. Shudder. I suppose if there are other callers(?) then we could hide it in a countargs.h and not include that into kernel.h.
On 12/04/2023 20.55, Andrew Morton wrote: > On Wed, 12 Apr 2023 15:56:43 +0300 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > >> On Tue, Apr 11, 2023 at 03:21:19PM -0700, Andrew Morton wrote: >>> On Tue, 11 Apr 2023 13:24:54 +0300 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: >>> >>>> kernel.h is being used as a dump for all kinds of stuff for a long time. >>>> The COUNT_ARGS() and CONCATENATE() macros may be used in some places >>>> without need of the full kernel.h dependency train with it. >>>> >>>> Here is the attempt on cleaning it up by splitting out these macros(). >>>> >>>> --- a/include/linux/kernel.h >>>> +++ b/include/linux/kernel.h >>>> @@ -13,6 +13,7 @@ >>>> >>>> #include <linux/stdarg.h> >>>> #include <linux/align.h> >>>> +#include <linux/args.h> >>> >>> A more energetic patch would have included args.h into each file which >>> calls COUNT_ARGS() and CONCATENATE(), and not included args.h into >>> kernel.h. And that appears to be very easy - only bpf uses these things? >>> >>> In fact these macros are so weird and ugly I'd be inclined to move them >>> into some bpf header so we don't have to see them again. No >>> args.h, which might avoid encouraging others to use them. >> >> We have more users than one > > I cant find any? True, git grep COUNT_ARGS doesn't find anything other than the bpf_probe.h user. >> and a couple of users that reimplement this macro >> under different names. >> > Where are these? Amusingly, bpf have at least tools/lib/bpf/bpf_core_read.h:#define ___narg(...) ___nth(_, ##__VA_ARGS__, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0) tools/lib/bpf/bpf_helpers.h: ___bpf_nth(_, ##__VA_ARGS__, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0) tools/lib/bpf/bpf_tracing.h:#define ___bpf_narg(...) ___bpf_nth(_, ##__VA_ARGS__, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0) OK, so that's under tools/, but we really should be able to make a cpp-tricks-header that's usable by the kernel itself as well as tools. There's also include/linux/arm-smccc.h: ___count_args(__VA_ARGS__, 7, 6, 5, 4, 3, 2, 1, 0) arch/x86/include/asm/rmwcc.h:#define RMWcc_ARGS(X...) __RMWcc_ARGS(, ##X, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0) and some efi_nargs that seems a little more elaborate (though I doubt they couldn't just make do with the standard macro). There's probably even more, this is just what grepping for a typical implementation showed. > What the heck does it do It counts the number of arguments given to a variadic macro. > and why is it so ugly Because cpp. > and why isn't it documented. Shudder. Yeah, some comments on how it works and its limitation(s) would probably be in order. Rasmus
diff --git a/include/linux/args.h b/include/linux/args.h new file mode 100644 index 000000000000..16ef6fad8add --- /dev/null +++ b/include/linux/args.h @@ -0,0 +1,13 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _LINUX_ARGS_H +#define _LINUX_ARGS_H + +/* This counts to 12. Any more, it will return 13th argument. */ +#define __COUNT_ARGS(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _n, X...) _n +#define COUNT_ARGS(X...) __COUNT_ARGS(, ##X, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0) + +#define __CONCAT(a, b) a ## b +#define CONCATENATE(a, b) __CONCAT(a, b) + +#endif /* _LINUX_ARGS_H */ diff --git a/include/linux/kernel.h b/include/linux/kernel.h index 0d91e0af0125..fa675d50d7b7 100644 --- a/include/linux/kernel.h +++ b/include/linux/kernel.h @@ -13,6 +13,7 @@ #include <linux/stdarg.h> #include <linux/align.h> +#include <linux/args.h> #include <linux/limits.h> #include <linux/linkage.h> #include <linux/stddef.h> @@ -457,13 +458,6 @@ ftrace_vprintk(const char *fmt, va_list ap) static inline void ftrace_dump(enum ftrace_dump_mode oops_dump_mode) { } #endif /* CONFIG_TRACING */ -/* This counts to 12. Any more, it will return 13th argument. */ -#define __COUNT_ARGS(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _n, X...) _n -#define COUNT_ARGS(X...) __COUNT_ARGS(, ##X, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0) - -#define __CONCAT(a, b) a ## b -#define CONCATENATE(a, b) __CONCAT(a, b) - /* Rebuild everything on CONFIG_FTRACE_MCOUNT_RECORD */ #ifdef CONFIG_FTRACE_MCOUNT_RECORD # define REBUILD_DUE_TO_FTRACE_MCOUNT_RECORD