linux-kernel - Re: [PATCH] watchdog: rn5t618: use proper module tables

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] [day] [month] [year] [list]

Message-ID: <2543aa99-0069-4eb1-a37b-204f3e6bbf6c@kernel.org>
Date: Thu, 19 Sep 2024 13:02:55 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Andreas Kemnade <andreas@...nade.info>, Guenter Roeck <linux@...ck-us.net>
Cc: wim@...ux-watchdog.org, linux-watchdog@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] watchdog: rn5t618: use proper module tables

On 19/09/2024 12:50, Andreas Kemnade wrote:
> Am Wed, 18 Sep 2024 15:43:40 -0700
> schrieb Guenter Roeck <linux@...ck-us.net>:
> 
>> On 9/18/24 14:29, Andreas Kemnade wrote:
>>> Avoid requiring MODULE_ALIASES by declaring proper device id tables.
>>>
>>> Signed-off-by: Andreas Kemnade <andreas@...nade.info>  
>>
>> This needs a better rationale. There are more than 40 watchdog drivers
>> using MODULE_ALIAS. I would hate having to deal with 40+ patches just
>> for cosmetic reasons, not counting the thousands of instances of
>> MODULE_ALIAS in the kernel, including the more than 1,000 instances of
>> "MODULE_ALIAS.*platform:".
>>
> basically reviewers were arguing against patches from me bringing in
> MODULE_ALIASES. So I decided to clean up a bit in my backyard. Not
> sure whether such things could by done by coccinelle but at least
> it could be tested via output of modinfo.
> 
> This is one example for such a patch:
> https://lore.kernel.org/linux-clk/119f56c8-5f38-eb48-7157-6033932f0430@linaro.org/
> 

There are multiple aspects here:
1. People (including me) copy code which they do no understand. Or
without really digging into it, because they do not have time. They just
copy it, regardless whether the code is necessary or not. MODULE_ALIAS
is one of such examples. It got copied to new drivers just because some
other driver had it.

2. MODULE_ALIAS creates basically ABI - some user-space might depend on
it, so removal might affect user. I think I was not dropping it from the
drivers in cases it would actually drop an alias. I was only dropping
duplicated aliases. That's not the case here, I believe.

3. MODULE_ALIAS scales poor. I believe proper xxx_device_id table is better.

4. But it does not mean that one single line - MODULE_ALIAS - should be
replaced in existing drivers into full-blown ID table. I think I never
proposed such patches for existing drivers. Why? Because if there was no
such need so far, means there were no scalability issues.

5. For new drivers I would propose to use ID table instead of
MODULE_ALIAS, even if it has one entry, because of above scalability.
But that's just my opinion and other person still might prefer might
concise ALIAS.

That's said, considering (4) above, I would not propose such patch. I
agree here with Guenter that you need proper rationale.

Best regards,
Krzysztof