Messages in this thread | | | Date | Sat, 23 Sep 2006 10:45:29 -0600 | From | Jim Cromie <> | Subject | Re: + doc-lockdep-design-explain-display-of-state-bits.patch added to -mm tree |
| |
Ingo Molnar wrote: > * Jim Cromie <jim.cromie@gmail.com> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |