mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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



      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®