Re: [PATCH v1 2/3] rust: core abstractions for HID drivers

[Danilo Krummrich <dakr@kernel.org>]

On 7/3/25 10:01 AM, Benjamin Tissoires wrote:
> On Jul 03 2025, Jiri Kosina wrote:
>> On Sun, 29 Jun 2025, Danilo Krummrich wrote:
>>
>>> (Cc: +Jiri)
>>
>> Thanks.
>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index c3f7fbd0d67a..487750d9fd1e 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -10686,6 +10686,13 @@ F:	include/uapi/linux/hid*
>>>>   F:	samples/hid/
>>>>   F:	tools/testing/selftests/hid/
>>>>   
>>>> +HID CORE LAYER [RUST]
>>>> +M:	Rahul Rameshbabu <sergeantsagara@protonmail.com>
>>>> +L:	linux-input@vger.kernel.org
>>>> +S:	Maintained
>>>> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git
>>>> +F:	rust/kernel/hid.rs
>>>
>>> I assume this is agreed with the HID CORE LAYER maintainers?
>>>
>>> There are multiple possible options, for instance:
>>>
>>>    1) Maintain the Rust abstractions as part of the existing MAINTAINERS entry.
>>>       Optionally, the author can be added as another maintainer or reviewer.
>>>
>>>    2) Add a separate MAINTAINERS entry; patches still go through the same
>>>       subsystem tree.
>>>
>>>    3) Add a separate MAINTAINERS entry; patches don't go through the subsystem
>>>       tree (e.g. because the subsystem maintainers don't want to deal with it).
>>
>> I can't speak for Benjamin, but as far as I am concerned, I'd personally
>> prefer option (3).
> 
> I understand Jiri's concerns, but I'm slighlty worried (3) will end up
> also having the leaf drivers in a separate tree, which means that 2
> trees will fight for the same resource.
> 
> First patch of this series is a first example where some changes are
> needed in the HID bus for making rust life's easier.
> 
> Personally, I'd like to have a say and an eye on the rust abstractions
> and most of it, on the leaf drivers. I can't say I'll proactively
> review/merge things (these past few months have shown that I merely
> manage to follow things happening ATM), but at least I can keep an eye
> and shout if something is wrong.
> 
> OTOH, the HID tree (the core part) is a low change tree now, so maybe a
> separate tree can be handled correctly without too much troubles.
> 
> Danilo, if a separate tree is chosen, is the common practice to directly
> send the PR to Linus or does it need to got through the subsystem tree
> first (like bpf with net for example).

We usually fall back to the global Rust tree, which is ultimately maintained by
Miguel, so it's his call in the end.

However, IMHO this is more like a "last resort" in case any other approaches 
within the same subsystem are not desired.

 From what I can read above, it feels to me as if having a separate tree
(maintained by Rahul) with him sending pull requests to you guys seems like a
good option. What do you think about that?