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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87msebyxtv.fsf@kernel.org>
Date: Mon, 24 Feb 2025 19:58:04 +0100
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "Boqun Feng" <boqun.feng@...il.com>
Cc: "Miguel Ojeda" <miguel.ojeda.sandonis@...il.com>,  "Frederic Weisbecker"
 <frederic@...nel.org>,  "Anna-Maria Behnsen" <anna-maria@...utronix.de>,
  "Thomas Gleixner" <tglx@...utronix.de>,  "Danilo Krummrich"
 <dakr@...nel.org>,  "Alex Gaynor" <alex.gaynor@...il.com>,  "Gary Guo"
 <gary@...yguo.net>,  Björn Roy Baron
 <bjorn3_gh@...tonmail.com>,  "Benno
 Lossin" <benno.lossin@...ton.me>,  "Alice Ryhl" <aliceryhl@...gle.com>,
  "Trevor Gross" <tmgross@...ch.edu>,  "Lyude Paul" <lyude@...hat.com>,
  "Guangbo Cui" <2407018371@...com>,  "Dirk Behme" <dirk.behme@...il.com>,
  "Daniel Almeida" <daniel.almeida@...labora.com>,  "Tamir Duberstein"
 <tamird@...il.com>,  <rust-for-linux@...r.kernel.org>,
  <linux-kernel@...r.kernel.org>,  "Miguel Ojeda" <ojeda@...nel.org>
Subject: Re: [PATCH v9 01/13] rust: hrtimer: introduce hrtimer support

"Boqun Feng" <boqun.feng@...il.com> 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@...il.com> 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