linux-kernel - Re: [PATCH v1 5/7] modpost: Create modalias for builtin modules

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 for Android: free password hash cracker in your pocket

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

Message-ID: <aBDs_Unta7-vOPk4@example.org>
Date: Tue, 29 Apr 2025 17:15:09 +0200
From: Alexey Gladkov <legion@...nel.org>
To: Petr Pavlu <petr.pavlu@...e.com>
Cc: Luis Chamberlain <mcgrof@...nel.org>,
	Sami Tolvanen <samitolvanen@...gle.com>,
	Daniel Gomez <da.gomez@...sung.com>,
	Masahiro Yamada <masahiroy@...nel.org>,
	Nathan Chancellor <nathan@...nel.org>,
	Nicolas Schier <nicolas.schier@...ux.dev>,
	linux-kernel@...r.kernel.org, linux-modules@...r.kernel.org,
	linux-kbuild@...r.kernel.org
Subject: Re: [PATCH v1 5/7] modpost: Create modalias for builtin modules

On Tue, Apr 29, 2025 at 04:14:13PM +0200, Petr Pavlu wrote:
> On 4/29/25 14:49, Alexey Gladkov wrote:
> > On Tue, Apr 29, 2025 at 12:04:44PM +0200, Alexey Gladkov wrote:
> >>> I'm not sure it's best to overload this data in this way. I think mixing
> >>> actual files and "logical" modules in the modules list is somewhat
> >>> confusing.
> >>>
> >>> An alternative would be to keep a single module struct for vmlinux and
> >>> record the discovered aliases under it?
> >>
> >> It is possible to extend struct module_alias and add the module name. The
> >> problem is that alias is added by module_alias_printf() and we will have
> >> to add the module name to the arguments to each do_entry handler in
> >> addition to struct module where there is already a name (but in our case
> >> it is vmlinux).
> >>
> >> I can do that if you think it's a better way.
> > 
> > If I don't add separate entries for each builtin module, the patch will
> > look like this:
> > [...]
> 
> I see, that didn't turn out as well as I envisioned. One more approach
> would be to track builtin modules separately. A patch is below. I'm not
> sure if it's better.

I'm not sure I get it. What do you mean when you say I need to track
builtin modules separately ?

-- 
Rgrds, legion