From: "Gary Guo" <gary@garyguo.net>
To: "Petr Pavlu" <ppavlu@suse.cz>, "Gary Guo" <gary@garyguo.net>
Cc: "Thiébaud Weksteen" <tweek@google.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
rust-for-linux@vger.kernel.org, linux-modules@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rust: macros: allow non-ASCII characters in `authors`
Date: Fri, 25 Sep 2026 13:49:38 +0100 [thread overview]
Message-ID: <DLOERNFT9KH0.E6BYORP7OCZM@garyguo.net> (raw)
In-Reply-To: <0ecdcba9-a0a5-456f-8d30-e2201828cd07@suse.cz>
On Fri Sep 25, 2026 at 1:36 PM BST, Petr Pavlu wrote:
> On 9/17/26 9:20 AM, Gary Guo wrote:
>> On Thu Sep 17, 2026 at 6:11 AM BST, =?UTF-8?q?Thi=C3=A9baud=20Weksteen?= wrote:
>>> Module authors may have non-ASCII characters in their names. In C,
>>> `MODULE_AUTHOR` allows arbitrary string literals which are emitted as
>>> raw UTF-8 bytes into the `.modinfo` section, and multiple in-tree
>>> modules use non-ASCII author names.
>>>
>>> Originally, the single `author` field permitted arbitrary string literals
>>> including non-ASCII characters. When support for multiple authors was
>>> introduced in commit 38559da6afb2 ("rust: module: introduce `authors`
>>> key"), it reused the `expect_string_array` helper that had originally been
>>> added for module aliases. Because that helper enforced an ASCII check,
>>> `authors` inadvertently became restricted to ASCII-only string literals.
>>> Later, when the macro parsing was rewritten to use `syn` in commit
>>> c578ad703ae9 ("rust: macros: use `syn` to parse `module!` macro"), this
>>> restriction was carried over by using AsciiLitStr in `authors` type.
>>>
>>> Change the element type of `authors` in `ModuleInfo` from `AsciiLitStr`
>>> to `LitStr` so that UTF-8 author names are permitted.
>>>
>>> Fixes: 38559da6afb2 ("rust: module: introduce `authors` key")
>>> Signed-off-by: Thiébaud Weksteen <tweek@google.com>
>>
>> Off topic, but I have a question for modules maintainers...
>>
>> Does the `authors` field still serve this purpose today?
>>
>> Almost always it is just the initial submitter, while the code has been subject
>> to many changes (many of them tree wide too), and the maintainers could have
>> changed as well.
>>
>> We have copyright comments on top of files, and git for checking the file
>> history. What's the point of keeping his inside module metadata?
>
> MODULE_AUTHOR() was apparently added in 2.1.18 back in 1996 [1], with
> a comment that it is for documentation purposes.
I am pretty sure the kernel changed a lot since then :)
>
> I don't have a full picture of how this modinfo field is currently used
> by module authors, maintainers and users. I think it can be useful as
> a record of all past and present primary authors of a specific module,
Well, if they're actually updated... But as pointed out that this was usually
not the case.
> and it has also value for external modules.
The version field has value for external modules too, but that was recently
removed. I don't think we should care about external modules too much.
> Unlike copyright statements
> and Git history, the information is directly visible to users through
> the modinfo utility.
Hmm, why does the user want to know who is the primary author of a module?
Users shouldn't try to contact the authors anyway, they should find the current
maintainers...
Even if the field is perfectly up-to-date, a user running an older kernel should
still not use this field as they need to contact the current mainline maintainer
if they have issues.
I just find this info to be hardly useful at all.
Best,
Gary
>
> It is up to individual module maintainers whether they want to use this
> field and maintain its information. The module loader doesn't enforce
> its setting in any way.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux-fullhistory.git/commit/?id=e69db0c2dafd9206cdc859b0361c6d4f07d77676
prev parent reply other threads:[~2026-09-25 12:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 5:11 Thiébaud Weksteen
2026-09-17 7:20 ` Gary Guo
2026-09-25 12:36 ` Petr Pavlu
2026-09-25 12:49 ` Gary Guo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DLOERNFT9KH0.E6BYORP7OCZM@garyguo.net \
--to=gary@garyguo.net \
--cc=aliceryhl@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=ppavlu@suse.cz \
--cc=rust-for-linux@vger.kernel.org \
--cc=tweek@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®