> Making a guard variant of chained_irq_enter/exit needs some thought and > a general plan for cleaning the whole chained irq usage up. It's on the > cleanup list already with quite some other items. I became also curious how API usage will evolve further here. > We are not adhoc adding a guard variant because guards are hip right now. Application interests are growing, aren't they? > And no this does not need a scoped variant ever. There are subsystems which seem to prefer such a programming interface occasionally. > guards are not the panacea for everything. Their usage might become more popular. Regards, Markus
