Re: [PATCH 1/2] drm: Add a non-locking version of drm_kms_helper_poll_enable(), v2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 25 Sep 2015, Egbert Eich <eich@xxxxxxxx> wrote:
> Jani Nikula writes:
>  > 
>  > Shouldn't this be _unlocked?
>  > 
>  > I thought the convention was that functions that do not acquire locks
>  > are called _unlocked (although they may require a lock to be held when
>  > called). And you might have foo() that grabs locks around a call to
>  > foo_unlocked().
>  > 
>
> Looking into this, functions that are to be called in a context where
> the lock is already held should receive the suffix _locked while
> those which do locking themselves and thus need to be called from
> a context that doesn't hold this lock already receive the suffix 
> _unlocked: the past tense refers to what has happened before.

I'm afraid existing conventions trump what makes sense.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux