[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANpmjNPsCVkq7SsVL-xpktGe3RsJnRGTJxEPZ60VUt1w_5QgPQ@mail.gmail.com>
Date: Mon, 20 Dec 2021 12:20:13 +0100
From: Marco Elver <elver@...gle.com>
To: Yajun Deng <yajun.deng@...ux.dev>
Cc: keescook@...omium.org, samitolvanen@...gle.com, ojeda@...nel.org,
masahiroy@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] init: fix the wrong __setup_param() definition
On Mon, 20 Dec 2021 at 04:55, Yajun Deng <yajun.deng@...ux.dev> wrote:
>
> The parameters in __setup_param() should be four rather than three when
> MODULE isn't definited.
This is actually "when MODULE is defined". __setup_param() becomes a
nop when compiling as a module.
But that begs the question: why hasn't this been caught before?
Probably because nobody should be using __setup_param() if something
can also be compiled as a module, in which case module_param() and
friends should be used. But perhaps there are valid usecases where i
t's meant to become a nop if MODULE.
I don't object this fix, since the !MODULE __setup_param() seems like
it was meant to be defined.
Just curious: did you actually encounter a problem with some new code
using __setup_param()?
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Yajun Deng <yajun.deng@...ux.dev>
> ---
> include/linux/init.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/init.h b/include/linux/init.h
> index d82b4b2e1d25..62a77850f10e 100644
> --- a/include/linux/init.h
> +++ b/include/linux/init.h
> @@ -355,7 +355,7 @@ void __init parse_early_options(char *cmdline);
>
> #else /* MODULE */
>
> -#define __setup_param(str, unique_id, fn) /* nothing */
> +#define __setup_param(str, unique_id, fn, early)/* nothing */
> #define __setup(str, func) /* nothing */
> #endif
>
> --
> 2.32.0
>
Powered by blists - more mailing lists