On Fri, 23 Jun 2006 13:52:54 +0200
Ingo Molnar <[email protected]> wrote:
>
> * Ingo Molnar <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
