So far the major items are:

* Performance evaluation of the changes, with these requirements:
* Support the same number of NMI nesting level we have now.
* Overflow detection for irq disable nest levels
* One major impact is that hardware access vs per-CPU memory access at each time we disable/enable irq.
* Maybe we can use `refscale` (kernel/rcu/refscale.c) as a skeletion for micro-benchmarking?
* Plan/tool/work of avoiding introduction of another irq disable/enable primitives.
* So what we have current is:
* `local_irq_disable()` and `local_irq_enable()`
* `local_irq_save()` and `local_irq_restore()`

* And what we are introducing is:
* `local_interrupt_disable()` and `local_interrupt_enable()`.

Boqun: Maybe we only need to prove that we can do this (not necessarily clean up at first)

Lyude: will need to get the kernel boot into a reasonable state to figure what are the creative use cases and how to detect and resolve them.

Boqun: Keep in mind the least we can do is implement a Rust version of `local_interrupt_disable()` and only use it in Rust for the moment.

If we want to avoid 3 sets of API in total, the thing we should do is using `local_interrupt_disable()` to replace either `local_irq_disable()` or `local_irq_save()`. My gut feeling is that replacing `local_irq_disable()` will be easier.

# Takeaways

* Figuring out long-term plan for converting APIs
* Performance concerns (lower priority)
* If we can't solve the performance concerns ATM/cannot deal with them, keeping the implementation limited to rust *might* be an option?
* Consider doing topic in plumbers to get more attention on some of the potential issues w/ conversion&performance (should be fine w/ long term plan, will let us decouple merging/blocking on conv&perf)
* Figuring out plan for handling performance issues before sending out next version (can be limiting usage, or showing that performance is fine)