[Intel-gfx] [PATCH 1/2] drm: Add a non-locking version of drm_kms_helper_poll_enable(), v2
Jani Nikula
jani.nikula at linux.intel.com
Fri Sep 25 00:52:51 PDT 2015
On Fri, 25 Sep 2015, Egbert Eich <eich at suse.com> 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
More information about the Intel-gfx
mailing list