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

[Ingo Molnar]

* 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.]

hm?

	Ingo
-
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/