Re: [patch 50/61] lock validator: special locking: hrtimer.c

[Andrew Morton]

On Fri, 23 Jun 2006 13:52:54 +0200
Ingo Molnar <mingo@xxxxxxx> wrote:

> 
> * Ingo Molnar <mingo@xxxxxxx> wrote:
> 
> > > > 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.
> > 
> > 'lock type' is what i tried to use consistenty.
> > 
> > > "class" would be a good term, although terribly overused.  Using that 
> > > as an example, spin_lock_init_standalone_class()?  ug.
> 
> actually ... 'class' might be an even better term than 'type', mainly 
> because type is even more overloaded in this context than class. "Q: 
> What type does this lock have?" The natural answer: "it's a spinlock".
> 
> so i'm strongly considering the renaming of 'lock type' to 'lock class' 
> and push that through all the APIs (and documentation). (i.e. we'd have 
> 'subclasses' of locks, not 'subtypes'.)
> 
> then we could do the annotations (where the call-site heuristics get the 
> class wrong and either do false splits or dont do a split) via:
> 
> 	spin_lock_set_class(&lock, &class_key)
> 	rwlock_set_class(&rwlock, &class_key)
> 	mutex_set_class(&mutex, &class_key)
> 	rwsem_set_class(&rwsem, &class_key)
> 
> [And for class-internal nesting, we'd have subclass nesting levels.]
> 

Works for me.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/