lkml.org 
[lkml]   [2011]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Locking in the clk API
Date
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


\
 
 \ /
  Last update: 2011-01-11 15:39    [W:0.229 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site