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

[Thomas Gleixner <tglx@linutronix.de>]

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