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

[Boqun Feng]

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.

> > 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 ;-)

Regards,
Boqun

> If it is just for local development, then I would expect the
> maintainers to simply disable Rust entirely. I guess that may be
> harder in the medium/long-term future, but currently, I don't see a
> big issue not enabling Rust while developing the C side, no?
> 
> Cheers,
> Miguel