Can it be more convenient if the "taskENTER_CRITICAL" return status and "taskEXIT_CRITICAL" restore it?

Hi folks:
the “taskENTER_CRITICAL” and “taskEXIT_CRITICAL” implementation on FreeRTOS are with void return and void parameter, so it cant backup each critical level cpu status in stack and then restore from stack.

may be in order to deal with the nest use scenario, these two functions imle with a nest counter in each TCB so that each task can remeber the nesting level of critical regison and then restore the cpu interrupt status.

but, did this identical with the return status version like others ? for example, another impl. with retun status is:

u32 enter_critical_section(void)
{
      status = get_cpsr();
      ............
      return status;
}
u32 leave_critical_section(u32 sr) 
{
     set_cpsr(sr);
}

the advantange of this is, if there are not only a interrupt flag(interrupt enable control bit in this situation) ,each critical level could have his own version of flag, which should identical with the value befre enter criticaon after this leve critical section exited.
so, maybe the global nesting counter cant do this.

so, can i have your opinion on this point, can the two impl. be identical in some degree?
or they have essential difference?

thank you!

The very early ports of FreeRTOS did stack the original interrupt status before disabling interrupts - but as FreeRTOS got ported to more and more architectures (some 40+ architectures) it became less easy to find a way that worked across all ports. The method used by FreeRTOS now is very portable, but we will be making some updates to the method for certain ports as we introduce some new features in the coming months. The ports that support interrupt nesting do have ISR versions of enter/exit critical macros that work this way already - the early ports of FreeRTOS didn’t support interrupt nesting though.

Thank you.
so, can you show me your opiniton towards these two imple. which one is better? and why.

@tugouxp At this point, the main reason to keep the existing design is to maintain API stability.

@rtel might know of some other considerations as well.