mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jessica Yu <jeyu@redhat.com>
To: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: linux-kernel@vger.kernel.org, Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: moduleparam: introduce core_param_named macro for non-modular code
Date: Mon, 21 Nov 2016 02:37:47 -0500	[thread overview]
Message-ID: <20161121073747.GA23523@packer-debian-8-amd64.digitalocean.com> (raw)
In-Reply-To: <20161115020000.14057-1-paul.gortmaker@windriver.com>

+++ Paul Gortmaker [14/11/16 21:00 -0500]:
>We have the case where module_param_named() in file "foo.c" for
>parameter myparam translates that into the bootarg for the
>non-modular use case as "foo.myparam=..."
>
>The problem exists where the use case with the filename and the
>dot prefix is established, but the code is then realized to be 100%
>non-modular, or is converted to non-modular.  Both of the existing
>macros like core_param() or setup_param() do not append such a
>prefix, so a straight conversion to either will break the existing
>use cases.
>
>Similarly, trying to embed a hard coded "foo." prefix on the name
>fails cpp syntax due to the special nature of "." in code.  So we add
>this parallel variant for the modular --> non-modular transition to
>preserve existing and documented use cases with such a prefix.

Hm, I'm not convinced we need a core_ counterpart to module_param_named
(that's nearly identical), when module_param_named already implements
all of the above. Plenty of non-modular code already use it (e.g.
workqueue, printk), and a prefix is automatically supplied (which can be
overridden) in the non-modular case. That should already meet your
requirements, no?

>Cc: Jessica Yu <jeyu@redhat.com>
>Cc: Rusty Russell <rusty@rustcorp.com.au>
>Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>---
>
>[Marking this RFC since I don't like the fact that it still requires
> non-modular code to use moduleparam.h -- one possible fix for that is
> to consider moving non-modular macros to a new param.h or similar. ]
>
> include/linux/moduleparam.h | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
>diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
>index 52666d90ca94..4f2b92345eb5 100644
>--- a/include/linux/moduleparam.h
>+++ b/include/linux/moduleparam.h
>@@ -269,6 +269,23 @@ static inline void kernel_param_unlock(struct module *mod)
> 	__module_param_call("", name, &param_ops_##type, &var, perm, -1, 0)
>
> /**
>+ * core_param_named - define a module compat core kernel parameter.
>+ * @name: the name of the cmdline and sysfs parameter (often the same as var)
>+ * @var: the variable
>+ * @type: the type of the parameter
>+ * @perm: visibility in sysfs
>+ *
>+ * core_param_named is just like module_param_named(), but cannot be modular
>+ * and it _does_ add a prefix (such as "printk.").  This is for compatibility
>+ * with module_param_named(), and it exists to provide boot arg compatibility
>+ * with code that was previously using the modular version with the prefix.
>+ */
>+#define core_param_named(name, var, type, perm)				\
>+	param_check_##type(name, &(var));				\
>+	__module_param_call(KBUILD_MODNAME ".", name, &param_ops_##type,\
>+			    &var, perm, -1, 0)
>+
>+/**
>  * core_param_unsafe - same as core_param but taints kernel
>  */
> #define core_param_unsafe(name, var, type, perm)		\
>-- 
>2.10.1
>

  parent reply	other threads:[~2016-11-21  7:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-15  2:00 [PATCH -RFC] " Paul Gortmaker
2016-11-16  2:11 ` Rusty Russell
2016-11-21  7:37 ` Jessica Yu [this message]
2016-11-21 15:37   ` Paul Gortmaker

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=20161121073747.GA23523@packer-debian-8-amd64.digitalocean.com \
    --to=jeyu@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul.gortmaker@windriver.com \
    --cc=rusty@rustcorp.com.au \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®