On Fri, 23 Jun 2006 12:04:39 +0200
Ingo Molnar <[email protected]> wrote:
>
> * Andrew Morton <[email protected]> wrote:
>
> > > for (i = 0; i < MAX_HRTIMER_BASES; i++, base++)
> > > - spin_lock_init(&base->lock);
> > > + spin_lock_init_static(&base->lock);
> > > }
> > >
> >
> > Perhaps the validator core's implementation of spin_lock_init() could
> > look at the address and work out if it's within the static storage
> > sections.
>
> yeah, but there are two cases: places where we want to 'unify' array
> locks into a single type, and places where we want to treat them
> separately. The case where we 'unify' is the more common one: locks
> embedded into hash-tables for example. So i went for annotating the ones
> that are rarer. There are 2 right now: scheduler, hrtimers, with the
> hrtimers one going away in the high-res-timers implementation. (we
> unified the hrtimers locks into a per-CPU lock) (there's also a kgdb
> annotation for -mm)
>
> 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.
"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().
-
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]
