Supporting Multiple Authors in Rust for Linux Modules

Overview

In the Rust for Linux project, each module is defined using the module! macro, which declares metadata such as the module’s name, license, and author.
However, until recently, the macro only supported a single author, defined as a String. This worked fine for small test modules, but it didn’t reflect how real kernel development happens — collaboratively.
To fix this, I introduced support for multiple authors in the Rust kernel module system, making it possible to declare modules with a list of authors instead of just one.
This post explains the motivation, implementation details, and upstream integration process for this change.

Motivation

The original module! macro looked like this:

	
module! {
    type: MyDriver,
    name: b"my_driver",
    author: b"John Doe",
    description: b"My example Rust module",
    license: b"GPL",
}

The author field was a String, so only one name could be set.
However, kernel modules are often written and maintained by multiple developers, sometimes from different companies. This limitation was inconsistent with the MODULE_AUTHOR() macro in C, which can be invoked multiple times to register several authors.
To address this, the Rust side needed to support multiple entries as well.

Implementation details

1. Changing the field type
The first step was to change the internal representation of the field inside the module! macro definition from:

author: Option<String>

to:

authors: Option<Vec<String>>

This allowed the macro to accept arrays of string literals, making multi-author definitions possible.

2. Updating the macro syntax
The syntax of the macro was updated to replace author with authors.
Here’s an example of the new form:

module! {
    type: MyDriver,
    name: b"my_driver",
    authors: ["John Doe", "Jane Smith"],
    description: b"My example Rust module with multiple authors",
    license: b"GPL",
}

Modules that still used the old author key continued to work temporarily for backward compatibility, but developers were encouraged to migrate to authors.

3. Handling backward compatibility
In the first patch, I added support for both keys:

author => converts to Vec with one element
authors => Vec directly

This ensured a smooth transition without breaking existing in-tree modules.
Later, once all in-tree modules had migrated, I submitted a second patch to remove the legacy author key entirely.

Example Before and After

Before (single author):

module! {
    type: HelloModule,
    name: b"hello",
    author: b"John Doe",
    description: b"A simple Rust hello-world kernel module",
    license: b"GPL",
}

After (multiple authors):

module! {
    type: HelloModule,
    name: b"hello",
    authors: ["John Doe", "Jane Smith"],
    description: b"A simple Rust hello-world kernel module",
    license: b"GPL",
}

This change gives the Rust kernel interface parity with the C API while maintaining Rust’s type safety and expressiveness.

Technical Challenges

Implementing this seemingly simple feature required careful handling of:
* Macro parsing and token matching in the Rust procedural macro.
* Type-level validation to ensure both backward and forward compatibility.
* Preserving ABI stability for kernel module metadata.
* Synchronizing changes across all in-tree Rust modules, ensuring no build breakages.

Because this code runs at the core of the kernel’s Rust infrastructure, even a small mistake could have broken the build system or module initialization.

Upstream Process

Like any kernel change, this required:
1. Submitting the patch series to rust-for-linux@vger.kernel.org
2. Undergoing review by maintainers
3. Iterating on feedback until the patches met all quality and consistency standards
4. Getting merged into the kernel tree

This process taught me a lot about kernel communication standards, maintainer expectations, and commit hygiene.

Impact

This improvement:
* Makes Rust module metadata more expressive.
* Brings feature parity with the C module macros.
* Simplifies future multi-contributor module development.
* Reduces technical debt by removing a deprecated API.

While small in code size, it’s meaningful in how it aligns Rust integration with Linux’s collaborative development model.

Conclusion

This contribution highlights that even small changes in the kernel can have large conceptual and structural effects.
Improving metadata like this helps make the Rust-for-Linux infrastructure more consistent and future-proof.
For those interested in contributing to the kernel — start small, understand the subsystem, and always think about maintainability and forward compatibility.<

References

Patch 1 – Introduce authors key
Patch 2 – Remove legacy author key