linux-kernel - Re: [PATCH v6 0/3] rust: Add irq abstraction, SpinLockIrq

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: <87iktrahld.ffs@tglx>
Date: Wed, 16 Oct 2024 23:00:30 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Boqun Feng <boqun.feng@...il.com>
Cc: Dirk Behme <dirk.behme@...il.com>, Lyude Paul <lyude@...hat.com>,
 rust-for-linux@...r.kernel.org, Danilo Krummrich <dakr@...hat.com>,
 airlied@...hat.com, Ingo Molnar <mingo@...hat.com>, Will Deacon
 <will@...nel.org>, Waiman Long <longman@...hat.com>, Peter Zijlstra
 <peterz@...radead.org>, linux-kernel@...r.kernel.org, Miguel Ojeda
 <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, Wedson Almeida
 Filho <wedsonaf@...il.com>, Gary Guo <gary@...yguo.net>, Björn Roy Baron
 <bjorn3_gh@...tonmail.com>, Benno Lossin <benno.lossin@...ton.me>, Andreas
 Hindborg <a.hindborg@...sung.com>, Alice Ryhl <aliceryhl@...gle.com>,
 Trevor Gross <tmgross@...ch.edu>
Subject: Re: [PATCH v6 0/3] rust: Add irq abstraction, SpinLockIrq

On Sun, Oct 13 2024 at 14:43, Boqun Feng wrote:
> On Sun, Oct 13, 2024 at 09:06:01PM +0200, Thomas Gleixner wrote:
> But that makes `cv.wait()` not working, because interrtups would be
> still disabled when schedule() is called.
>
> I'm waiting for Lyude's new version (with lock_first(), and
> unlock_last()) to see how we can resolve this. We may need to redesign
> `CondVar::wait`.

Thinking more about this. I think there is a more general problem here.

Much of the rust effort today is trying to emulate the existing way how
the C implementations work.

I think that's fundamentally wrong because a lot of the programming
patterns in the kernel are fundamentally wrong in C as well. They are
just proliferated technical debt.

What should be done is to look at it from the rust perspective in the
first place: How should this stuff be implemented correctly?

Then you work from there and go the extra mile to create some creative
workarounds at the abstraction level instead of trying to mimic the
existing C nonsense.

Which in turn gives you a way cleaner pattern of implementing stuff in
rust.

Stop worrying about mostly irrelevant low level details which are not
relevant to the primary audience of rust adoption. We can worry about
them when we replace the scheduler and the low level interrupt handling
code ten years down the road.

Please focus on providing a sane and efficient programming environment
to get actual stuff (drivers) into the rust domain.

Thanks,

        tglx