linux-kernel - Re: [PATCH -RFC] moduleparam: introduce core_param

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87vavoxjfc.fsf@rustcorp.com.au>
Date:   Wed, 16 Nov 2016 12:41:51 +1030
From:   Rusty Russell <rusty@...tcorp.com.au>
To:     Paul Gortmaker <paul.gortmaker@...driver.com>,
        linux-kernel@...r.kernel.org
Cc:     Paul Gortmaker <paul.gortmaker@...driver.com>,
        Jessica Yu <jeyu@...hat.com>
Subject: Re: [PATCH -RFC] moduleparam: introduce core_param_named macro for non-modular code

Paul Gortmaker <paul.gortmaker@...driver.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.