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

[Ingo Molnar]

* Andrew Morton <akpm@xxxxxxxx> 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.
> 
> <gives up>
> 
> You want spin_lock_init_singleton().

hehe ;)

singleton wouldnt be enough here as we dont want just one instance of 
this lock type: we want separate types for each array entry. I.e. we 
dont want to unify the lock types (as the common spin_lock_init() call 
suggests), we want to split them along their static addresses.

singleton initialization is what spin_lock_init() itself accomplishes: 
the first call to a given spin_lock_init() will register a 'lock type' 
structure, and all subsequent calls to spin_lock_init() will find this 
type registered already. (keyed by the lockdep-type-key embedded in the 
spin_lock_init() macro)

so - spin_lock_init_split_type() might be better i think and expresses 
the purpose (to split away this type from the other lock types 
initialized here).

Or we could simply get rid of this static-variables special-case and 
embedd a lock_type_key in the runqueue and use 
spin_lock_init_key(&rq->rq_lock_key)? That would unify the 'splitting' 
of types for static and dynamic locks. (at a minimal cost of .data) 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/