On 11/11/21 11:32, Mike Galbraith wrote: > On Thu, 2021-11-11 at 10:36 +0100, Marco Elver wrote: >> I guess the question is if is_preempt_full() should be true also if >> is_preempt_rt() is true? > > That's what CONFIG_PREEMPTION is. More could follow, but it was added > to allow multiple models to say "preemptible". > That's what I was gonna say, but you can have CONFIG_PREEMPTION while being is_preempt_none() due to PREEMPT_DYNAMIC... >> Not sure all cases are happy with that, e.g. the kernel/trace/trace.c >> case, which wants to print the precise preemption level. > > Yeah, that's the "annoying" bit, needing one oddball model accessor > that isn't about a particular model. > >> To avoid confusion, I'd introduce another helper that says true if the >> preemption level is "at least full", currently that'd be "full or rt". >> Something like is_preempt_full_or_rt() (but might as well write >> "is_preempt_full() || is_preempt_rt()"), or is_preemption() (to match >> that Kconfig variable, although it's slightly confusing). The >> implementation of that helper can just be a static inline function >> returning "is_preempt_full() || is_preempt_rt()". >> >> Would that help? > > Yeah, as it sits two accessors are needed, one that says PREEMPT the > other PREEMPTION, spelling optional. > Per the above, I think we need the full || rt thingie. > -Mike
