From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965464AbcBQSNm (ORCPT ); Wed, 17 Feb 2016 13:13:42 -0500 Received: from tex.lwn.net ([70.33.254.29]:52327 "EHLO vena.lwn.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030241AbcBQSNl (ORCPT ); Wed, 17 Feb 2016 13:13:41 -0500 Date: Wed, 17 Feb 2016 11:13:38 -0700 From: Jonathan Corbet To: Tejun Heo Cc: Mark Brown , Paolo Valente , Jens Axboe , Fabio Checconi , Arianna Avanzini , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, ulf.hansson@linaro.org, linus.walleij@linaro.org Subject: Re: [PATCH RFC 09/22] block, cfq: replace CFQ with the BFQ-v0 I/O scheduler Message-ID: <20160217111338.205bcaeb@lwn.net> In-Reply-To: <20160217170429.GV3741@mtj.duckdns.org> References: <1454364778-25179-1-git-send-email-paolo.valente@linaro.org> <1454364778-25179-10-git-send-email-paolo.valente@linaro.org> <20160211222210.GC3741@mtj.duckdns.org> <20160212003502.GD1953@sirena.org.uk> <20160217155721.GT3741@mtj.duckdns.org> <20160217160209.GV7544@sirena.org.uk> <20160217170429.GV3741@mtj.duckdns.org> Organization: LWN.net X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 17 Feb 2016 12:04:29 -0500 Tejun Heo wrote: > idk, istr this coming up some months ago and there really weren't good > arguments for furthering out-of-line generated docs. I'm sure there > are people building and checking for errors but that doesn't indicate > the actual usefulness or that we shouldn't move away from it. This might come as a real surprise to the subsystems that are putting a lot of work into said docs. *You* might not find them useful but, for example, the DRM folks have told me that they credit better docs with an increase in the quality of the code submissions they are getting. Much of that work is inline, but in the code is not always the best place for everything. There's a set of us working to improve the generation system, making it so that even ordinary kernel developers can manage to get it to work. Sorry if you don't this stuff useful, but I hope you'll not mind if others keep the documentation in good form? In the case that started this discussion, it's the out-of-line generation that raises the alarm when things do go out of sync, helping to keep the docs current. jon