From: Rusty Russell <rusty@rustcorp.com.au>
To: Paul Gortmaker <paul.gortmaker@windriver.com>,
        linux-kernel@vger.kernel.org
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>,
        Jessica Yu <jeyu@redhat.com>
Subject: Re: [PATCH -RFC] moduleparam: introduce core_param_named macro for non-modular code
In-Reply-To: <20161115020000.14057-1-paul.gortmaker@windriver.com>
References: <20161115020000.14057-1-paul.gortmaker@windriver.com>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Wed, 16 Nov 2016 12:41:51 +1030
Message-ID: <87vavoxjfc.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 837
Lines: 22

Paul Gortmaker <paul.gortmaker@windriver.com> writes:
> 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.

IMHO you should keep using moduleparam.

I originally called everything simply param(), but there was a name
clash.

Linus' answer was basically that "everything is a module, even if it's
not a .ko".  And it's his tree, so he must be right!

Cheers,
Rusty.