Re: [PATCH v9 01/13] rust: hrtimer: introduce hrtimer support

[Andreas Hindborg]

"Boqun Feng" <boqun.feng@xxxxxxxxx> writes:

> On Mon, Feb 24, 2025 at 05:45:03PM +0100, Miguel Ojeda wrote:
>> On Mon, Feb 24, 2025 at 5:31 PM Boqun Feng <boqun.feng@xxxxxxxxx> wrote:
>> >
>> > On Mon, Feb 24, 2025 at 05:23:59PM +0100, Miguel Ojeda wrote:
>> > >
>> > > side -- Andreas and I discussed it the other day. The description of
>> > > the issue has some lines, but perhaps the commit message could
>> >
>> > Do you have a link to the issue?
>>
>> Sorry, I meant "description of the symbol", i.e. the description field
>> in the patch.
>>
>
> Oh, I see. Yes, the patch description should provide more information
> about what the kconfig means for hrtimer maintainers' development.

Right, I neglected to update the commit message. I will do that if we
have another version.

>
>> > I asked because hrtimer API is always available regardless of the
>> > configuration, and it's such a core API, so it should always be there
>> > (Rust or C).
>>
>> It may not make sense for something that is always built on the C
>> side, yeah. I think the intention here may be that one can easily
>> disable it while "developing" a change on the C side. I am not sure
>> what "developing" means here, though, and we need to be careful --
>> after all, Kconfig options are visible to users and they do not care
>> about that.
>>
>
> Personally, I don't think CONFIG_RUST_HRTIMER is necessarily because as
> you mentioned below, people can disable Rust entirely during
> "developing".
>
> And if I understand the intention correctly, the CONFIG_RUST_HRTIMER
> config provides hrtimer maintainers a way that they could disable Rust
> hrtimer abstraction (while enabling other Rust component) when they're
> developing a change on the C side, right? If so, it's hrtimer
> maintainers' call, and this patch should provide more information on
> this.
>
> Back to my personal opinion, I don't think this is necessary ;-)
> Particularly because I can fix if something breaks Rust side, and I'm
> confident and happy to do so for hrtimer ;-)

As Miguel said, the idea for this came up in the past week in one of the
mega threads discussing rust in general. We had a lot of "what happens
if I change something in my subsystem and that breaks rust" kind of
discussions.

For subsystems where the people maintaining the C subsystem is not the
same people maintaining the Rust abstractions, this switch might be
valuable. It would allow making breaking changes to the C code of a
subsystem without refactoring the Rust code in the same sitting. Rather
than having to disable rust entirely - or going and commenting out lines
in the kernel crate - I think it is better to provide an option to just
disable building these particular bindings.

This has nothing to do with general policies related to breakage between
Rust and C code, and how to fix such breakage in a timely manner. It is
simply a useful switch for disabling part of the build so that people
can move on with their business, while someone else scrambles to fix
whatever needs fixing on the Rust side.

I am of course also available to fix anything that would eventually
break. In fact, I expect to be able to catch breakage most of the time
automatically and very early by means of automatically monitoring the
relevant trees. I do this for block, and it has worked really well since
rust code was merged in that subsystem.


Best regards,
Andreas Hindborg