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

["Boqun Feng" <boqun.feng@gmail.com>]

On Wed, Oct 16, 2024, at 2:00 PM, Thomas Gleixner wrote:
> 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?
>

I totally agree. One of things that can help is handling nested interruption
disabling differently: we can do something similar as preemption disable,
i.e. using a percpu counter to record the level of interrupt disabling,
as a result, SpinLockIrq::lock() just increases the counter and return the
Guard, when the Guard drops the counter decreases. In this way, no matter
what’s the order of Guard dropping, we remain correctly on interrupt disable
states. I can implement a new set of local_irq_*() in this way and let Rust use
this. Thoughts?

Regards,
Boqun

> 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