linux-kernel - Re: [PATCH v9 02/10] rockchip-mailbox: Fix typo

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]

Date:   Mon, 09 Jan 2023 11:54:43 +0000
From:   Nick Alcock <nick.alcock@...cle.com>
To:     Luis Chamberlain <mcgrof@...nel.org>
Cc:     Allen Webb <allenwebb@...gle.com>,
        Nick Alcock <nick.alcock@...cle.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-modules@...r.kernel.org" <linux-modules@...r.kernel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>, stable@...r.kernel.org,
        kernel test robot <lkp@...el.com>
Subject: Re: [PATCH v9 02/10] rockchip-mailbox: Fix typo

On 20 Dec 2022, Luis Chamberlain uttered the following:
>> It also raises the question how many modules have device tables, but
>> do not call MODULE_DEVICE_TABLE since they are only ever built-in.
>> Maybe there should be some build time enforcement mechanism to make
>> sure that these are consistent.
>
> Definitely, Nick Alcock is doing some related work where the semantics
> of built-in modules needs to be clearer, he for instance is now removing
> a few MODULE_() macros for things which *are never* modules, and this is
> because after commit 8b41fc4454e ("kbuild: create modules.builtin
> without Makefile.modbuiltin or tristate.conf") we rely on the module
> license tag to generate the modules.builtin file. Without that commit
> we end up traversing the source tree twice. Nick's work builds on
> that work and futher clarifies these semantics by adding tooling which
> complains when something which is *never* capable of being a module
> uses module macros. The macro you are extending, MODULE_DEVICE_TABLE(),
> today is a no-op for built-in, but you are adding support to extend it
> for built-in stuff. Nick's work will help with clarifying symbol locality
> and so he may be interested in your association for the data in
> MODULE_DEVICE_TABLE and how you associate to a respective would-be
> module. His work is useful for making tracing more accurate with respect
> to symbol associations, so the data in MODULE_DEVICE_TABLE() may be
> useful as well to him.

The kallmodsyms module info (and, thus, modules.builtin) and
MODULE_DEVICE_TABLE do seem interestingly related. I wonder if we can in
future reuse at least the module names so we can save a few KiB more
space... (in this case, the canonical copy should probably be the one in
kallmodsyms, because that lets kallmodsyms reuse strings where modules
and their source file have similar names. Something for the future...)

> You folks may want to Cc each other on your patches.

I'd welcome that.

btw, do you want another kallmodsyms patch series from me just arranging
to drop fewer MODULE_ entries from non-modules (just MODULE_LICENSE) or
would this be considered noise for now? (Are we deadlocked on each
other, or are you still looking at the last series I sent, which I think
was v10 in late November?)

-- 
NULL && (void)