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: <Z79B4brrB_-SBstl@localhost.localdomain>
Date: Wed, 26 Feb 2025 17:31:29 +0100
From: Frederic Weisbecker <frederic@...nel.org>
To: Andreas Hindborg <a.hindborg@...nel.org>
Cc: Boqun Feng <boqun.feng@...il.com>,
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	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

Le Mon, Feb 24, 2025 at 08:52:35PM +0100, Andreas Hindborg a écrit :
> > It's of course up to hrtimer maintainers. But I personally nack this
> > kconfig, because it's not necessary, and hrtimer API has been stable for
> > a while.
> 
> Having the switch is fine for me, removing it is fine as well. It's just
> an added convenience that might come in handy. But having this kconfig
> very close to zero overhead, so I do not really understand your
> objection. I would like to better understand your reasoning.

If you choose to make a such a Kconfig switch, it would only make sense
in order to spare some bytes when no drivers use it for example. But if
you're afraid that the Rust binding is on the way while the core is
changing some API then I guess simply disabling Rust would be enough for
testing.

I don't think it's necessary (unless it's strictly selected by drivers).
But it's your call.

Thanks.

> 
> 
> Best regards,
> Andreas Hindborg
> 
>