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

[Rahul Rameshbabu <sergeantsagara@protonmail.com>]

On Thu, 03 Jul, 2025 10:20:19 +0200 "Danilo Krummrich" <dakr@kernel.org> wrote:
> 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?

First wanted to say thanks to everyone who responded to this series.
I am personally open to any of the above.

From what I can tell, Jiri and Benjamin would prefer pull
requests/discussion of the Rust for Linux bindings not contaminate the
hid git tree or linux-input mailing list. Patches will instead be
submitted through the rust-for-linux mailing list and pull requests
would be sent through the Rust for Linux tree. I can make Benjamin a
reviewer for this effort, so he will be explicitly CCed to take a look
at how the bindings are taking shape. I can make Jiri a reviewer if he
would like to participate (I was assuming maybe not based on the desire
for option 3 listed above). Maybe with this model, I have a
rust-for-linux-hid tree where I send pull requests to the rust-for-linux
tree?

On the other hand, Danilo would prefer something similar to the above
with the caveat of pull requests going through the hid tree and patches
through linux-input mailing list.

I am open to either personally.

I will be sending a v2 hopefully soon based on Danilo's and Peter's
feedback.

In parallel, I am thinking about how to design a Drop trait for handling
HID device unplug instead of needing a C style remove callback. This
will be crucial for implementing sophisticated leaf drivers. The driver
implemented here purely does report fixup. In my ideal world, all pure
report fixup work would be done in HID-BPF space and only sophisticated
drivers would be implemented as a Rust leaf driver. I have some separate
scratch work playing around HID-BPF that I have not had time to clean
up. Right now, it's just samples for doing things like key remapping on
a keyboard. I am envisioning an Alsa UCM like model for HID-BPF for
dealing with report fixups.

-- 
Thanks,

Rahul Rameshbabu