From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756789AbcJGP6x (ORCPT ); Fri, 7 Oct 2016 11:58:53 -0400 Received: from mail-oi0-f54.google.com ([209.85.218.54]:35668 "EHLO mail-oi0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752798AbcJGP6o (ORCPT ); Fri, 7 Oct 2016 11:58:44 -0400 MIME-Version: 1.0 In-Reply-To: <20161007154351.GL3117@twins.programming.kicks-ass.net> References: <20161007145243.361481786@infradead.org> <20161007150210.927453282@infradead.org> <20161007154351.GL3117@twins.programming.kicks-ass.net> From: Linus Torvalds Date: Fri, 7 Oct 2016 08:58:43 -0700 X-Google-Sender-Auth: lKG9JOBBL3AZaSQCjFCHx6aIx3M Message-ID: Subject: Re: [PATCH -v4 1/8] locking/drm: Kill mutex trickery To: Peter Zijlstra Cc: Waiman Long , Jason Low , Ding Tianhong , Thomas Gleixner , Will Deacon , Ingo Molnar , Imre Deak , Linux Kernel Mailing List , Davidlohr Bueso , Tim Chen , Terry Rudd , "Paul E. McKenney" , Chris Wilson , Daniel Vetter , Rob Clark Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 7, 2016 at 8:43 AM, Peter Zijlstra wrote: > > So something like the below would serve as a replacement for your > previous hacks. Is this API something acceptable to people? Ingo, > Thomas? Ugh. I think the concept is fine, but can we place make these enum's be all upper case or something to make them really stand out visually. Also, it's a bit subtle how this depends on the success/failure enums to just have the same values as the return value of the non-try mutex. So a comment about why that particular numbering is important above the enum definition, please? You _kind_ of imply that magic numbering requirementby explicitly using " = 0" and " = 1", but quite frankly, in many ways that's really nasty, because I can see somebody looking at that enum definition and saying "that makes no sense: it sets *two* of the three values explicitly, and the values it sets explicitly are the same that it would get implicitly _anyway_, so I'll just clean this up". So I really think that enum needs a comment on the forced choice of values, and making them all caps would make the users more obvious, I think. The other choice would be to just make the choices be negative (== recursive), zero (== failed) or positive (== got lock), which allows for the same value re-use for the non-recursive case, and you could avoid the enum entirely. Linus