From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751701AbdEPLRN (ORCPT ); Tue, 16 May 2017 07:17:13 -0400 Received: from merlin.infradead.org ([205.233.59.134]:58420 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750784AbdEPLRL (ORCPT ); Tue, 16 May 2017 07:17:11 -0400 Date: Tue, 16 May 2017 13:16:56 +0200 From: Peter Zijlstra To: Mauro Carvalho Chehab Cc: Jani Nikula , Darren Hart , linux-kernel@vger.kernel.org, Linux Doc Mailing List , Mauro Carvalho Chehab , Ingo Molnar , Thomas Gleixner Subject: Re: [PATCH 04/36] mutex, futex: adjust kernel-doc markups to generate ReST Message-ID: <20170516111656.g3uxmcmule2wqlot@hirez.programming.kicks-ass.net> References: <20170512164122.GA17235@fury> <20170512185150.5b48c5f6@vento.lan> <20170512221109.r6yuazrjpikrkg6d@hirez.programming.kicks-ass.net> <20170512221917.GD17235@fury> <20170515070348.htsggm7rgggaqrpd@hirez.programming.kicks-ass.net> <20170515060046.7ba700c7@vento.lan> <20170515093312.eaymomgkcetvpofc@hirez.programming.kicks-ass.net> <874lwmmmzd.fsf@intel.com> <20170515114919.bepernrqonybkmmh@hirez.programming.kicks-ass.net> <20170515142239.00389f0b@vento.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170515142239.00389f0b@vento.lan> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 15, 2017 at 02:22:39PM -0300, Mauro Carvalho Chehab wrote: > Yet, on the other hand, nobody wants lots of warnings/errors > produced when building the Kernel or the documentation, as it can ride > important things that would require fixes. So would that actually generate a warn/error? Or just generate weird output? Because I'm perfectly fine with weird output. Our primary interface to the code is a text editor, and things should be readable in that form. Anything that detracts from that is a fail. If people like to use web browsers (I don't) then I won't stop them, but they have to realize they're the odd ducks out for viewing things outside its native form. > diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c > index 198527a62149..858a07590e39 100644 > --- a/kernel/locking/mutex.c > +++ b/kernel/locking/mutex.c > @@ -227,9 +227,9 @@ static void __sched __mutex_lock_slowpath(struct mutex *lock); > * (or statically defined) before it can be locked. memset()-ing > * the mutex to 0 is not allowed. > * > - * ( The CONFIG_DEBUG_MUTEXES .config option turns on debugging > - * checks that will enforce the restrictions and will also do > - * deadlock debugging. ) > + * (The CONFIG_DEBUG_MUTEXES .config option turns on debugging > + * checks that will enforce the restrictions and will also do > + * deadlock debugging) > * > * This function is similar to (but not equivalent to) down(). > */ > > >