lkml.org 
[lkml]   [2006]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2006-06-23 13:01    [W:3.976 / U:0.076 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site