mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Gary Guo" <gary@garyguo.net>
To: "Thiébaud Weksteen" <tweek@google.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>
Cc: <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: Thu, 17 Sep 2026 08:20:57 +0100	[thread overview]
Message-ID: <DLHERMQ9DOIC.1TRR4M82WNLIZ@garyguo.net> (raw)
In-Reply-To: <20260917051147.98775-1-tweek@google.com>

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?

Best,
Gary

> ---
>  rust/macros/lib.rs    | 2 +-
>  rust/macros/module.rs | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/rust/macros/lib.rs b/rust/macros/lib.rs
> index 24f96feaeb34..ea2e232b61b1 100644
> --- a/rust/macros/lib.rs
> +++ b/rust/macros/lib.rs
> @@ -129,7 +129,7 @@
>  /// # Supported argument types
>  ///   - `type`: type which implements the [`Module`] trait (required).
>  ///   - `name`: ASCII string literal of the name of the kernel module (required).
> -///   - `authors`: array of ASCII string literals of the authors of the kernel module.
> +///   - `authors`: array of string literals of the authors of the kernel module.
>  ///   - `description`: string literal of the description of the kernel module.
>  ///   - `license`: ASCII string literal of the license of the kernel module (required).
>  ///   - `alias`: array of ASCII string literals of the alias names of the kernel module.
> diff --git a/rust/macros/module.rs b/rust/macros/module.rs
> index bc7027f8dbb2..0a7b9e24c960 100644
> --- a/rust/macros/module.rs
> +++ b/rust/macros/module.rs
> @@ -369,7 +369,7 @@ pub(crate) struct ModuleInfo {
>      type_: Type,
>      license: AsciiLitStr,
>      name: AsciiLitStr,
> -    authors: Option<Punctuated<AsciiLitStr, Token![,]>>,
> +    authors: Option<Punctuated<LitStr, Token![,]>>,
>      description: Option<LitStr>,
>      alias: Option<Punctuated<AsciiLitStr, Token![,]>>,
>      firmware: Option<Punctuated<AsciiLitStr, Token![,]>>,

      reply	other threads:[~2026-09-17  7:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-17  5:11 Thiébaud Weksteen
2026-09-17  7:20 ` 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=DLHERMQ9DOIC.1TRR4M82WNLIZ@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=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®