* Andreas Dilger <adil...@dilger.ca> wrote:
> > On Dec 6, 2017, at 17:49, Ingo Molnar <mi...@kernel.org> wrote:
> >
> > This exposes some waitqueue internals, but AFAICS the FUSE code already
> > does a
> > similar trick with fiq->waitq.lock so there's precedent.
>
> What about waitqueue_lock() and waitqueue_unlock() helpers that
> lock and unlock, to avoid exposing the internals? Or would that add
> confusion by making users think they need their own waitqueue locking?
Right now there are just two users (FUSE and epoll), and both are
well-maintained,
essentially core kernel code - I'd rather prefer the readability of explicitly
writing out the locking/unlocking pattern.
So while it's a mild layering violation, it's also a valid looking optimization.
Thanks,
Ingo
