Messages in this thread | | | Date | Sat, 15 Jan 2011 20:30:55 +0000 | From | Russell King - ARM Linux <> | Subject | Re: Locking in the clk API |
| |
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: > > You really need to read the entire thread - I've already said that yet > >> 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.
>> 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.
| |