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)