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: <Z7yl-LsSkVIDAfMF@Mac.home>
Date: Mon, 24 Feb 2025 09:01:44 -0800
From: Boqun Feng <boqun.feng@...il.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Andreas Hindborg <a.hindborg@...nel.org>,
	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

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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ