All of lore.kernel.org
 help / color / mirror / Atom feed
From: Saravana Kannan <saravanak@google.com>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	Aaron Tomlin <atomlin@redhat.com>,
	Christoph Lameter <cl@linux.com>, Miroslav Benes <mbenes@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jessica Yu <jeyu@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-modules@vger.kernel.org, void@manifault.com,
	atomlin@atomlin.com, Allen Pais <allen.lkml@gmail.com>,
	Joe Perches <joe@perches.com>,
	Michal Suchanek <msuchanek@suse.de>,
	Oleksandr Natalenko <oleksandr@natalenko.name>,
	Jason Wessel <jason.wessel@windriver.com>,
	Petr Mladek <pmladek@suse.com>,
	Daniel Thompson <daniel.thompson@linaro.org>,
	Christoph Hellwig <hch@infradead.org>,
	Android Kernel Team <kernel-team@android.com>
Subject: Re: [PATCH v1] module: Fix prefix for module.sig_enforce module param
Date: Thu, 2 Jun 2022 20:48:41 -0700	[thread overview]
Message-ID: <CAGETcx-gEbH2ymx7FXCXZNt3p=r=5FXuhLUiMuNvofcb1HXysA@mail.gmail.com> (raw)
In-Reply-To: <YplAxCvRiNnthK6d@bombadil.infradead.org>

On Thu, Jun 2, 2022 at 3:59 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> On Thu, Jun 02, 2022 at 02:47:04PM -0700, Saravana Kannan wrote:
> > On Thu, Jun 2, 2022 at 12:41 PM Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > >
> > > On Thu, Jun 2, 2022 at 12:16 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> > > >
> > > > Linus want to take this in or should I just queue these up?
> > >
> > > I'll take it, and remove the unnecessary #ifdef/#endif. The #undef
> > > might as well be unconditional - simpler and doesn't hurt.
> >
> > Sounds good. I just copy-pasted how it was done elsewhere. Luis was
> > mentioning adding a wrapper to go this cleanly and I needed it in
> > another instance too. So I'll look into doing that in a future patch.
>
> Virtual hug, or something hippie like that.

Thanks :)

I gave this a shot.

+ #define set_module_param_prefix(prefix) \
+ #undef MODULE_PARAM_PREFIX              \
+ #define MODULE_PARAM_PREFIX prefix

I even wrote up a nice chunk of "function doc" before I tried
compiling it. And once I compiled it, I was smacked in the head by the
compiler for trying to put a #define inside a #define (Duh, the
preprocessing in a single pass).

Before I tried this, I looked up the current uses of the "hacky" snippet:

$ git grep -l "define.*MODULE_PARAM_PREFIX" -- :^include/
block/disk-events.c
drivers/misc/cxl/fault.c
drivers/mmc/core/block.c
drivers/pci/pcie/aspm.c
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
drivers/tty/serial/8250/8250_core.c
drivers/xen/balloon.c
drivers/xen/events/events_base.c
kernel/debug/kdb/kdb_main.c
kernel/kcsan/core.c
kernel/rcu/tree.c
kernel/rcu/update.c
mm/damon/reclaim.c
mm/kfence/core.c


In a lot of those files, there are a lot of module params that follow
this snippet. Going on a tangent, some of the uses of #define
MODULE_PARAM_PREFIX don't seem to have any obvious use or param
macros.

So adding a module_param_prefixed() doesn't make sense to me either,
because I'll have to repeat the same prefix in every usage of
module_param_prefixed() AND I'll have to create a _prefixed() variant
for other param macros too.

So, something like:
module_param_prefixed("module.", sig_enforce, bool, 644);
module_param_prefixed("module.", another_param1, bool, 644);
module_param_prefixed("module.", another_param2, bool, 644);

Or replace "module." with a MY_PREFIX so that it's easy to ensure the
string is the same across each use:
#define MY_PREFIX "module."
module_param_prefixed(MY_PREFIX, sig_enforce, bool, 644);
module_param_prefixed(MY_PREFIX, another_param1, bool, 644);
module_param_prefixed(MY_PREFIX, another_param2, bool, 644);

But at that point, all I'm avoiding is one #undef MODULE_PARAM_PREFIX
and a whole lot of code churn.

One other option is to do something like:
#ifndef MOD_PREFIX
#define MODULE_PARAM_PREFIX KBUILD_MODNAME "."
#else
#define MODULE_PARAM_PREFIX MOD_PREFIX "."
#endif

But that will have the limitation that MOD_PREFIX has to be defined
before any #includes is in a file (similar to pr_fmt())  and doesn't
allow you to redefine the prefix half way through a file -- which is
also a thing that happens in drivers/tty/serial/8250/8250_core.c.

So, long story short, none of these options sound especially appealing
that it's worth all the code churn across multiple maintainer trees.
Let me know if you have other ideas that might work or you think one
of the options I dismissed is actually worth doing.

Thanks,
Saravana

  reply	other threads:[~2022-06-03  3:49 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-22 14:03 [PATCH v12 00/14] module: core code clean up Aaron Tomlin
2022-03-22 14:03 ` [PATCH v12 01/14] module: Move all into module/ Aaron Tomlin
2022-06-02  3:41   ` Saravana Kannan
2022-06-02 19:14     ` Luis Chamberlain
2022-06-02  3:56   ` [PATCH v1] module: Fix prefix for module.sig_enforce module param Saravana Kannan
2022-06-02 19:16     ` Luis Chamberlain
2022-06-02 19:40       ` Linus Torvalds
2022-06-02 21:47         ` Saravana Kannan
2022-06-02 22:59           ` Luis Chamberlain
2022-06-03  3:48             ` Saravana Kannan [this message]
2022-06-03  4:30               ` Randy Dunlap
2022-06-02 19:35     ` Aaron Tomlin
2022-03-22 14:03 ` [PATCH v12 02/14] module: Simple refactor in preparation for split Aaron Tomlin
2022-03-22 14:03 ` [PATCH v12 03/14] module: Make internal.h and decompress.c more compliant Aaron Tomlin
2022-03-22 14:03 ` [PATCH v12 04/14] module: Move livepatch support to a separate file Aaron Tomlin
2022-03-22 14:03 ` [PATCH v12 05/14] module: Move latched RB-tree " Aaron Tomlin
2022-03-22 14:03 ` [PATCH v12 06/14] module: Move strict rwx " Aaron Tomlin
2022-03-22 14:03 ` [PATCH v12 07/14] module: Move extra signature support out of core code Aaron Tomlin
2022-03-22 14:03 ` [PATCH v12 08/14] module: Move kmemleak support to a separate file Aaron Tomlin
2022-03-22 14:03 ` [PATCH v12 09/14] module: Move kallsyms support into " Aaron Tomlin
2022-03-22 14:03 ` [PATCH v12 10/14] module: kallsyms: Fix suspicious rcu usage Aaron Tomlin
2022-03-22 14:03 ` [PATCH v12 11/14] module: Move procfs support into a separate file Aaron Tomlin
2022-03-22 14:03 ` [PATCH v12 12/14] module: Move sysfs " Aaron Tomlin
2022-03-22 14:03 ` [PATCH v12 13/14] module: Move kdb module related code out of main kdb code Aaron Tomlin
2022-03-22 14:03 ` [PATCH v12 14/14] module: Move version support into a separate file Aaron Tomlin
2022-03-22 15:41 ` [PATCH v12 00/14] module: core code clean up Michal Suchánek
2022-03-22 17:23 ` Luis Chamberlain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGETcx-gEbH2ymx7FXCXZNt3p=r=5FXuhLUiMuNvofcb1HXysA@mail.gmail.com' \
    --to=saravanak@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=allen.lkml@gmail.com \
    --cc=atomlin@atomlin.com \
    --cc=atomlin@redhat.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=cl@linux.com \
    --cc=daniel.thompson@linaro.org \
    --cc=hch@infradead.org \
    --cc=jason.wessel@windriver.com \
    --cc=jeyu@kernel.org \
    --cc=joe@perches.com \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=mcgrof@kernel.org \
    --cc=msuchanek@suse.de \
    --cc=oleksandr@natalenko.name \
    --cc=pmladek@suse.com \
    --cc=torvalds@linux-foundation.org \
    --cc=void@manifault.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.