Messages in this thread | | | Date | Fri, 23 Jun 2006 12:52:55 +0200 | From | Ingo Molnar <> | Subject | Re: [patch 50/61] lock validator: special locking: hrtimer.c |
| |
* Andrew Morton <akpm@osdl.org> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |