shared config registers and locking

[Michael Galassi]

>Now, more seriously, of course the thing will boil down to a spinlock.
>My point was what do you guys think about having one shared spinlock
>exposed by the powerpc platform code for use by all those little bits
>here or there that whack global configuration registers like clock
>control things, etc... that we have all over the place on embedded
>processors.

GACK!  Many better engineers than any of us have spent countless hours
breaking down locks.  A lock takes nearly no space at all, you're not
proposing to lock any less often, so multiple locks take no less time,
the only thing you stand to gain by protecting multiple data structures
with one lock is the possibility of lock contention.  Please reconsider.

I can envision situations in which you might want to have a lock
protecting more than one item in code which is local to your project,
company, group, whatever, feel free to do do so in that circumstance
but limit this practice to individual, carefully thought out, *LOCAL*
situations, don't allow that to propagate.  Please?  Pretty please?

>Since I don't like exposing a naked data structure though, rather than
>exposing the spinlock itself, I was proposing to expose an API of two
>functions (just in case we want to do something fancy) though they could
>well end up being inline and thus boil down to the same...

Linux needs another api just as much as we need another war in the
middle east or a third term of our commander in chief.  Just say no.

It turns out that any place you have any business manipulating a lock
associated with some data you're probably doing so in preparation to
manipulate that data.  By using a simple, well known interface such as
spin_lock_irqsave/spin_unlock_irqrestore you are actually making clear
what your code is doing, you are alerting the reader that you've
considered locking issues.  This is a good thing.

-michael