>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 _______________________________________________ Linuxppc-embedded mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
