Ingo Molnar wrote:
> * Jim Cromie <[email protected]> wrote:
>
>
>
>> btw '?' carries *is this really what you want ?* connotations. Is
>> that intended ? If not, maybe '=' is better.. 2 lines --> 'both'
>>
>
> well i dont see '=' any better than '?'.
>
>
let me rephrase.
for someone who knows intimately what they mean, how the flags are
rendered is unimportant.
but for someone who is looking to understand what lockdep
errors/messages mean,
they may look for hints in the the choice of flag-char, which could
convey 'severity'
! - something went bang, oh shit
* - splatted on landing
? - huh? - did you mean to do this ?
_ - blank, unspecified ..
It could be that making any such inferences is looking for hints that
dont exist,
otoh - if some messages are more severe, it would make sense to connote
that in the
choice of symbols to represent the flags/states.
IOW, were I to find a lockdep errmsg with {--??} vs {--..} in dmesg,
would it warrant any extra attention (as in *fix-me-first*) ? or just
investigated
>>> [ btw.: truly '....' locks are candiates for optimization, as they
>>> unnecessarily disable interrupts in process context. ]
>>>
>> is that a future optimization, needing another pair of
>> functions/macros ?
>>
>
> it means they dont really have to be spin_lock_irq()/spin_unlock_irq()
> uses but spin_lock()/spin_unlock() would be enough. (but it's not
> guaranted - some rare codepath that has not triggered yet might use
> those locks from IRQ context, at which point the irq-safety in process
> context is compulsory.)
>
Thats helpful. So continuing this line..
If joe-hacker were to falsely optimize, and then trigger the rare path
later,
would the lockdep errmsg contain { ??}, or do I oversimplify ?
> Ingo
>
>
thanks