Thread (86 messages) 86 messages, 20 authors, 2011-01-28

Locking in the clk API

From: Russell King - ARM Linux <hidden>
Date: 2011-01-15 20:31:45
Also in: linux-sh, lkml

On Sat, Jan 15, 2011 at 06:44:22PM +0100, Christer Weinigel wrote:
On 01/15/2011 06:20 PM, Russell King - ARM Linux wrote:
quoted
You really need to read the entire thread - I've already said that yet
quoted
discussion continues about how to solve the problem.  This thread which
has been running for a number of days now has been entirely about how
to solve this.

Sigh, the always oh so polite Russell.  I have read the thread before; I  
reread the whole thread one more time before posting.
Look, the clk API unification issue has been rattling around for six months
or more not making very much progress.  Should it continue to be discussed
for another six months while nothing happens because agreement can't be
reached?

Do you not realise what you suggested has already been proposed?

Does it help the discussion to have more people coming into the discussion
saying "we should do X" when we've already had people suggesting that we
should already do X - and we've had people saying afterwards "we should
do Y"?

Do you really think that you saying "we should do X" means that we'll have
lots of people suddenly saying "oh yes, you're right" when they didn't
before?

It's covering old ground over and over again.  Raising the same points
over and over again is just a pointless waste of time - it just sends the
discussion around the same loops time and time again.  Nothing actually
ever gets resolved but lots of time gets wasted discussing it.
quoted
Consider this: is it better to continue talking about this for the next
six months, while still having N spinlock based implementations, and M
mutex based implementations.

Or is it better to consolidate the N spinlock based implementations
down to one spinlock implementation, and M mutex based implementations
down to one mutex implementation, and then discuss how to resolve the
differences between the two implementations?

Going that way might very well mean that you will be stuck with two  
implementations forever.  But yes, it might be better with two working  
ones than one which takes a bit longer to finish.

But my impression is that the different suggestions in the thread aren't  
that far apart.  Except for the discussion if clk_enable/disable should  
be able to sleep or not, people seem to agree on most of the rest of the  
API.
As I said, at this point I _really_ don't care what happens provided
it doesn't end up screwing the facilities enjoyed by the existing
implementations.

I'm tired of reading this discussion.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help