MAINTAINERS | 4 ++++ 1 file changed, 4 insertions(+)
I realized that these files were never listed in MAINTAINERS when they
were added in commit ad37bcd965fd ("rust: add tracepoint support").
I'm proposing to include them under the existing entries, as that seems
like the most obvious place to include them. However, there are multiple
ways to do this. If you prefer to have them elsewhere, I would also be
happy to create a new entry with me as maintaining them, or I'm also
willing to be listed as R: under the entry. Regardless of how we list
them in MAINTAINERS, I will be around if anything comes up. Let me know
what you all prefer.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
Based on v6.19-rc1.
I noticed it due to this patch:
https://patch.msgid.link/20260105-define-rust-helper-v2-9-51da5f454a67@google.com
---
MAINTAINERS | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5b11839cba9de1e9e43f63787578edd8c429ca39..14eafd3fb428483cfd3f0a86f52d0c62ba7436e5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -25017,6 +25017,9 @@ F: include/linux/jump_label*.h
F: include/linux/static_call*.h
F: kernel/jump_label.c
F: kernel/static_call*.c
+F: rust/helpers/jump_label.c
+F: rust/kernel/generated_arch_static_branch_asm.rs.S
+F: rust/kernel/jump_label.rs
STI AUDIO (ASoC) DRIVERS
M: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
@@ -26470,6 +26473,7 @@ F: include/linux/trace*.h
F: include/trace/
F: kernel/trace/
F: kernel/tracepoint.c
+F: rust/kernel/tracepoint.rs
F: scripts/tracing/
F: scripts/tracepoint-update.c
F: tools/testing/selftests/ftrace/
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20260107-jump-label-rust-maintainers-17040992e7db
Best regards,
--
Alice Ryhl <aliceryhl@google.com>On Wed, Jan 7, 2026 at 1:32 PM Alice Ryhl <aliceryhl@google.com> wrote: > > I'm proposing to include them under the existing entries, as that seems > like the most obvious place to include them. However, there are multiple > ways to do this. If you prefer to have them elsewhere, I would also be > happy to create a new entry with me as maintaining them, or I'm also > willing to be listed as R: under the entry. Regardless of how we list > them in MAINTAINERS, I will be around if anything comes up. Let me know > what you all prefer. I think this was meant to go after the `---`? Whatever Steven et al. are happy with, this looks fine, thanks! Acked-by: Miguel Ojeda <ojeda@kernel.org> Cheers, Miguel
On Sun, 11 Jan 2026 19:36:29 +0100 Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > On Wed, Jan 7, 2026 at 1:32 PM Alice Ryhl <aliceryhl@google.com> wrote: > > > > I'm proposing to include them under the existing entries, as that seems > > like the most obvious place to include them. However, there are multiple > > ways to do this. If you prefer to have them elsewhere, I would also be > > happy to create a new entry with me as maintaining them, or I'm also > > willing to be listed as R: under the entry. Regardless of how we list > > them in MAINTAINERS, I will be around if anything comes up. Let me know > > what you all prefer. > > I think this was meant to go after the `---`? > > Whatever Steven et al. are happy with, this looks fine, thanks! > > Acked-by: Miguel Ojeda <ojeda@kernel.org> > I guess the question is are those with expertise on the list of people to Cc? I think it may be better to have a separate section for RUST so that the rust maintainers can be included in the M: part too. Perhaps: STATIC BRANCH/CALL (RUST) and TRACING (RUST) And have the M of the other sections be R here? -- Steve
On Mon, Jan 12, 2026 at 4:00 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> I guess the question is are those with expertise on the list of people to
> Cc?
>
> I think it may be better to have a separate section for RUST so that the
> rust maintainers can be included in the M: part too. Perhaps:
>
> STATIC BRANCH/CALL (RUST)
>
> and
>
> TRACING (RUST)
>
> And have the M of the other sections be R here?
There are several ways subsystems have gone about it:
- Sometimes they may just add the people to the existing entry.
- Sometimes they create sub-entries like you suggest (usually with
square brackets like " [RUST]" but there is also a " - RUST" used),
e.g.
BLOCK LAYER DEVICE DRIVER API [RUST]
MEMORY MANAGEMENT - RUST
- Sometimes they add them into the existing entry but with an added
"(RUST)" after their names, e.g. Boqun in LOCKING PRIMITIVES:
M: Boqun Feng <boqun.feng@gmail.com> (LOCKDEP & RUST)
Cheers,
Miguel
On Mon, 12 Jan 2026 16:11:40 +0100 Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > There are several ways subsystems have gone about it: > > - Sometimes they may just add the people to the existing entry. > > - Sometimes they create sub-entries like you suggest (usually with > square brackets like " [RUST]" but there is also a " - RUST" used), > e.g. > > BLOCK LAYER DEVICE DRIVER API [RUST] > MEMORY MANAGEMENT - RUST > > - Sometimes they add them into the existing entry but with an added > "(RUST)" after their names, e.g. Boqun in LOCKING PRIMITIVES: > > M: Boqun Feng <boqun.feng@gmail.com> (LOCKDEP & RUST) OK, add "[RUST]" instead ;-) -- Steve
On Mon, Jan 12, 2026 at 10:00:06AM -0500, Steven Rostedt wrote: > On Sun, 11 Jan 2026 19:36:29 +0100 > Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > > > On Wed, Jan 7, 2026 at 1:32 PM Alice Ryhl <aliceryhl@google.com> wrote: > > > > > > I'm proposing to include them under the existing entries, as that seems > > > like the most obvious place to include them. However, there are multiple > > > ways to do this. If you prefer to have them elsewhere, I would also be > > > happy to create a new entry with me as maintaining them, or I'm also > > > willing to be listed as R: under the entry. Regardless of how we list > > > them in MAINTAINERS, I will be around if anything comes up. Let me know > > > what you all prefer. > > > > I think this was meant to go after the `---`? > > > > Whatever Steven et al. are happy with, this looks fine, thanks! > > > > Acked-by: Miguel Ojeda <ojeda@kernel.org> > > > > I guess the question is are those with expertise on the list of people to > Cc? I would be on cc either way as RUST includes F: rust/. > I think it may be better to have a separate section for RUST so that the > rust maintainers can be included in the M: part too. Perhaps: > > STATIC BRANCH/CALL (RUST) > > and > > TRACING (RUST) > > And have the M of the other sections be R here? Sure, we can do that. Are you still willing to pick up the patches? I think that is simpler in case there are any series that touch both the C and Rust parts. (Such as the initial tracepoint series did.) Alice
On Mon, 12 Jan 2026 15:10:31 +0000 Alice Ryhl <aliceryhl@google.com> wrote: > > And have the M of the other sections be R here? > > Sure, we can do that. > > Are you still willing to pick up the patches? I think that is simpler in > case there are any series that touch both the C and Rust parts. (Such as > the initial tracepoint series did.) Yes. So I guess you can still add me with a 'M:'. But I wanted a separate section so that all the Rust expertise is still included. -- Steve
On Mon, Jan 12, 2026 at 11:54:08AM -0500, Steven Rostedt wrote: > On Mon, 12 Jan 2026 15:10:31 +0000 > Alice Ryhl <aliceryhl@google.com> wrote: > > > > And have the M of the other sections be R here? > > > > Sure, we can do that. > > > > Are you still willing to pick up the patches? I think that is simpler in > > case there are any series that touch both the C and Rust parts. (Such as > > the initial tracepoint series did.) > > Yes. So I guess you can still add me with a 'M:'. But I wanted a separate > section so that all the Rust expertise is still included. What about the STATIC BRANCH/CALL subsystem? Should I also leave you or someone else as 'M:' there? It's unclear to me who usually picks up patches for STATIC BRANCH/CALL when they are not a dependency to a patch for somewhere else. Alice
On Mon, Jan 26, 2026 at 12:27:10PM +0000, Alice Ryhl wrote: > On Mon, Jan 12, 2026 at 11:54:08AM -0500, Steven Rostedt wrote: > > On Mon, 12 Jan 2026 15:10:31 +0000 > > Alice Ryhl <aliceryhl@google.com> wrote: > > > > > > And have the M of the other sections be R here? > > > > > > Sure, we can do that. > > > > > > Are you still willing to pick up the patches? I think that is simpler in > > > case there are any series that touch both the C and Rust parts. (Such as > > > the initial tracepoint series did.) > > > > Yes. So I guess you can still add me with a 'M:'. But I wanted a separate > > section so that all the Rust expertise is still included. > > What about the STATIC BRANCH/CALL subsystem? Should I also leave you or > someone else as 'M:' there? It's unclear to me who usually picks up > patches for STATIC BRANCH/CALL when they are not a dependency to a patch > for somewhere else. I think that'd be me -- I typically do the static branch/call bits.
On Mon, Jan 26, 2026 at 10:37 PM Peter Zijlstra <peterz@infradead.org> wrote: > > On Mon, Jan 26, 2026 at 12:27:10PM +0000, Alice Ryhl wrote: > > On Mon, Jan 12, 2026 at 11:54:08AM -0500, Steven Rostedt wrote: > > > On Mon, 12 Jan 2026 15:10:31 +0000 > > > Alice Ryhl <aliceryhl@google.com> wrote: > > > > > > > > And have the M of the other sections be R here? > > > > > > > > Sure, we can do that. > > > > > > > > Are you still willing to pick up the patches? I think that is simpler in > > > > case there are any series that touch both the C and Rust parts. (Such as > > > > the initial tracepoint series did.) > > > > > > Yes. So I guess you can still add me with a 'M:'. But I wanted a separate > > > section so that all the Rust expertise is still included. > > > > What about the STATIC BRANCH/CALL subsystem? Should I also leave you or > > someone else as 'M:' there? It's unclear to me who usually picks up > > patches for STATIC BRANCH/CALL when they are not a dependency to a patch > > for somewhere else. > > I think that'd be me -- I typically do the static branch/call bits. Ah, thanks for the clarification. Are you ok with using the approach Steven suggested for STATIC BRANCH/CALL subsystem too? That is, add a [RUST] entry below the current one, list you and me as M:, and anyone else in the main entry as R:, and patches land through the same tree as where they would have landed if they were a C patch. I'm open to whichever setup you prefer, but I think it'd be nice to get these files into MAINTAINERS somewhere. Alice
On Mon, Jan 26, 2026 at 10:58:24PM +0100, Alice Ryhl wrote:
> > > What about the STATIC BRANCH/CALL subsystem? Should I also leave you or
> > > someone else as 'M:' there? It's unclear to me who usually picks up
> > > patches for STATIC BRANCH/CALL when they are not a dependency to a patch
> > > for somewhere else.
> >
> > I think that'd be me -- I typically do the static branch/call bits.
>
> Ah, thanks for the clarification.
>
> Are you ok with using the approach Steven suggested for STATIC
> BRANCH/CALL subsystem too? That is, add a [RUST] entry below the
> current one, list you and me as M:, and anyone else in the main entry
> as R:, and patches land through the same tree as where they would have
> landed if they were a C patch.
>
> I'm open to whichever setup you prefer, but I think it'd be nice to
> get these files into MAINTAINERS somewhere.
Yeah, I suppose that'll work. That [RUST] entry seems to be the
predominant style in MAINTAINERS.
My only concern is that most of the [RUST] entries don't actually
include the F entries for the !rust part, which means that if the C bits
change the Rust people aren't notified.
So I would suggest having all F duplicated from the main entry and then
add the rust files. Or, like we did with ATOMIC, just add you as M to
the main entry, along with a few rust files.
Some day I might actually learn enough to not see it as line noise :/
See 2387fb2a9b84 ("rust: sync: Add basic atomic operation mapping framework")
On Tue, Jan 27, 2026 at 9:24 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, Jan 26, 2026 at 10:58:24PM +0100, Alice Ryhl wrote:
>
> > > > What about the STATIC BRANCH/CALL subsystem? Should I also leave you or
> > > > someone else as 'M:' there? It's unclear to me who usually picks up
> > > > patches for STATIC BRANCH/CALL when they are not a dependency to a patch
> > > > for somewhere else.
> > >
> > > I think that'd be me -- I typically do the static branch/call bits.
> >
> > Ah, thanks for the clarification.
> >
> > Are you ok with using the approach Steven suggested for STATIC
> > BRANCH/CALL subsystem too? That is, add a [RUST] entry below the
> > current one, list you and me as M:, and anyone else in the main entry
> > as R:, and patches land through the same tree as where they would have
> > landed if they were a C patch.
> >
> > I'm open to whichever setup you prefer, but I think it'd be nice to
> > get these files into MAINTAINERS somewhere.
>
> Yeah, I suppose that'll work. That [RUST] entry seems to be the
> predominant style in MAINTAINERS.
>
> My only concern is that most of the [RUST] entries don't actually
> include the F entries for the !rust part, which means that if the C bits
> change the Rust people aren't notified.
>
> So I would suggest having all F duplicated from the main entry and then
> add the rust files. Or, like we did with ATOMIC, just add you as M to
> the main entry, along with a few rust files.
Ok, that makes sense to me as well. Let's do that. Sending v2 now ...
> Some day I might actually learn enough to not see it as line noise :/
>
> See 2387fb2a9b84 ("rust: sync: Add basic atomic operation mapping framework")
>
© 2016 - 2026 Red Hat, Inc.