Messages in this thread | | | From | Jeremy Kerr <> | Subject | Re: Locking in the clk API | Date | Tue, 11 Jan 2011 22:35:42 +0800 |
| |
Hi Paul,
> Again, you are approaching it from the angle that an atomic clock is a > special requirement rather than the default behaviour.
I'm not considering it a special requirement, but it's still a requirement (that the called function does not sleep).
The problem with the inverse logic (clk_enable/clk_enable_sleepable) is that now you've made the caller need to know what kind of clock it has, or might have one day.
* For clk_enable/clk_enable_atomic, the decision is: is this call in an atomic context?
* For clk_enable/clk_enable_sleepable, the decision is: might the clock code have given us a sleeping clock?
Note that it's much easier to guarantee correctness for the first than it is for the second.
Cheers,
Jeremy
| |