Messages in this thread | | | Date | Fri, 23 Jun 2006 03:38:25 -0700 | From | Andrew Morton <> | Subject | Re: [patch 50/61] lock validator: special locking: hrtimer.c |
| |
On Fri, 23 Jun 2006 12:04:39 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> > * Andrew Morton <akpm@osdl.org> wrote: > > > > for (i = 0; i < MAX_HRTIMER_BASES; i++, base++) > > > - spin_lock_init(&base->lock); > > > + spin_lock_init_static(&base->lock); > > > } > > > > > > > Perhaps the validator core's implementation of spin_lock_init() could > > look at the address and work out if it's within the static storage > > sections. > > yeah, but there are two cases: places where we want to 'unify' array > locks into a single type, and places where we want to treat them > separately. The case where we 'unify' is the more common one: locks > embedded into hash-tables for example. So i went for annotating the ones > that are rarer. There are 2 right now: scheduler, hrtimers, with the > hrtimers one going away in the high-res-timers implementation. (we > unified the hrtimers locks into a per-CPU lock) (there's also a kgdb > annotation for -mm) > > perhaps the naming should be clearer? I had it named > spin_lock_init_standalone() originally, then cleaned it up to be > spin_lock_init_static(). Maybe the original name is better? >
hm. This is where a "term of art" is needed. What is lockdep's internal term for locks-of-a-different-type? It should have such a term.
"class" would be a good term, although terribly overused. Using that as an example, spin_lock_init_standalone_class()? ug.
<gives up>
You want spin_lock_init_singleton(). - 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/
| |