Re: [RFC RESEND v10 03/14] irq & spin_lock: Add counted interrupt disabling/enabling

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

On Mon, Jun 16, 2025 at 01:54:47PM -0400, Joel Fernandes wrote:
[..]
> > > 
> > > Your SOB is placed wrong, should be below Boqun's. This way it gets
> > > lost.
> > > 
> > > Also, is there effort planned to fully remove the save/restore variant?
> > > As before, my main objection is adding variants with overlapping
> > > functionality while not cleaning up the pre-existing code.
> > > 
> > 
> > My plan is to map local_irq_disable() to local_interrupt_disable() and
> > keep local_irq_save() as it is. That is, local_irq_disable() is the
> > auto-pilot version and local_irq_save/restore() is the manual version.
> > The reason is that I can see more "creative" (i.e. unpaired) usage of
> > local_irq_save/restore(), and maybe someone would like to keep them.
> > Thoughts?
> 
> My thought is it is better to keep them separate at first, let
> local_interrupt_disable() stabilize with a few users, then convert the
> callers (possibly with deprecation warnings with checkpatch), and then remove
> the old API.
> 

No objection to doing it slowly ;-) My point was more about the plan is
to replace local_irq_disable() with local_interrupt_disable() other than
replacing local_irq_save() with local_interrupt_disable().
local_irq_save() will still be available for "power users" if they care
about precise control of irq disabling. But it's not necessary to be
done at the moment.

> That appears lowest risk and easier transition.
> 

Agreed. Thanks for looking into this.

Regards,
Boqun

> thanks,
> 
>  - Joel
>