Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3364169ybb; Tue, 31 Mar 2020 03:51:24 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvIIvAy9GXPQxwzWCs2ejw3EvsxOYP/S3kPfkpJM4DAehClnxglv7z0MibRazZNbtFWFWC0 X-Received: by 2002:aca:1c13:: with SMTP id c19mr1532917oic.178.1585651883913; Tue, 31 Mar 2020 03:51:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585651883; cv=none; d=google.com; s=arc-20160816; b=EDLk89q4YsObum61KAWwzKcrczZa3INYMqrpcJirwbXAqHgWmwnlPb99jrP4l4L1is bLyY7KjLKzX4Xfu8WkzQug627GWrshgCUPgHAfMWkFDf3b8WZIn/1IJcPAITflOZR8nw Fmmtt8Xey/ujjEtoMcsWeNi7AUphXmTH97onAhKonsXGlvvcM8Zs10zHE608ZV2L2lC7 CY3DUzxNT2tmWfYcOeoMuLYllM6eoqLskoli6al11+KAbQbh3aZ7/AKTPAAROLkAhceO lw174nuxq53rMTeRcdg0o+5td8mGpp5NOc0STYeOWQ2oJD7yCOX+2RvIkvKjqT+pAOV+ oc0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :organization:in-reply-to:subject:cc:to:from:ironport-sdr :ironport-sdr; bh=Zwy0RM3z5DHLZAOh8tTTTmCLfgHB7otloJbx2/aIIdI=; b=l32kOADUvBelRAx2xP2gKksWJqrLROAln304KX7zvo/yjx/c9oFzaj43ruHRRYD0Aw gm69ixgkVSg8YepGOdSPmLMkFvVPZovT6ilXywq7sfJ8B0grle2QhqIexG6Nj8MIx/hi +xHhPtGisPUajb9t32CKCKSzQsZw5SCnwoJtQJLMeXRxpjKgEblhq3OAc5xxnMtuSLgL SqEe54IiRf7OvsXNy2h7d8sTsE61a2lqUL8ZANfSoKWRR8GAzdkK9C639b8AiMtAqTN3 Plr9pdKQXvCNRk3Lq0oI4lzixgAg1kT1dbHTbqEvaA6h9eAsV6sNWMYIOnQb2rKnOVL0 DOTQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f23si608295oti.69.2020.03.31.03.51.11; Tue, 31 Mar 2020 03:51:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730400AbgCaKuU (ORCPT + 99 others); Tue, 31 Mar 2020 06:50:20 -0400 Received: from mga14.intel.com ([192.55.52.115]:60412 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730334AbgCaKuT (ORCPT ); Tue, 31 Mar 2020 06:50:19 -0400 IronPort-SDR: 6N3+p9g2GPFr213W6+QPQ5anU4prJIU0Es2HR/K4WwlVsvUrCImzRblTdC2JP/7XbtoVCncdHM COCIpurndnFQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Mar 2020 03:50:19 -0700 IronPort-SDR: 7ZdsGnayby9LSlUmAMcalf9gYIQYKT0i8scMQNoonNhigi0Ho0g3Qr69ndtFg+P5kFKWpyB7st J43LhNPNzCBQ== X-IronPort-AV: E=Sophos;i="5.72,327,1580803200"; d="scan'208";a="422252454" Received: from unknown (HELO localhost) ([10.249.38.166]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Mar 2020 03:50:15 -0700 From: Jani Nikula To: Matthew Wilcox , Jonathan Corbet Cc: peter@bikeshed.quignogs.org.uk, linux-kernel@vger.kernel.org, Greg Kroah-Hartman , "Rafael J. Wysocki" , linux-doc@vger.kernel.org Subject: Re: [PATCH v3 0/1] Compactly make code examples into literal blocks In-Reply-To: <20200327165022.GP22483@bombadil.infradead.org> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20200326192947.GM22483@bombadil.infradead.org> <20200326195156.11858-1-peter@bikeshed.quignogs.org.uk> <87imiqghop.fsf@intel.com> <20200327104126.667b5d5b@lwn.net> <20200327165022.GP22483@bombadil.infradead.org> Date: Tue, 31 Mar 2020 13:50:11 +0300 Message-ID: <87zhbwg5ng.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 27 Mar 2020, Matthew Wilcox wrote: > On Fri, Mar 27, 2020 at 10:41:26AM -0600, Jonathan Corbet wrote: >> On Fri, 27 Mar 2020 13:28:54 +0200 >> Jani Nikula wrote: >> >> > IMHO the real problem is kernel-doc doing too much preprocessing on the >> > input, preventing us from doing what would be the sensible thing in >> > rst. The more we try to fix the problem by adding more kernel-doc >> > processing, the further we dig ourselves into this hole. >> > >> > If kernel-doc didn't have its own notion of section headers, such as >> > "example:", we wouldn't have this problem to begin with. We could just >> > use the usual rst construct; "example::" followed by an indented block. >> > >> > I'm not going to stand in the way of the patch, but I'm telling you, >> > this is going to get harder, not easier, on this path. >> >> I agree with you in principle. The problem, of course, is that this is a >> legacy gift from before the RST days and it will be hard to change. >> >> A quick grep shows that the pattern: >> >> * Example: >> >> appears nearly 100 times in current kernels. It is not inconceivable to >> make a push to get rid of all of those, turning them into ordinary RST >> syntax - especially since not all of those are actually kerneldoc >> comments. >> >> The same quick grep says that "returns?:" appears about 10,000 times. >> *That* will be painful to change, and I can only imagine that some >> resistance would have to be overcome at some point. >> >> So what do folks think we should do? :) > > Let me just check I understand Jani's proposal here. You want to change > > * Return: Number of pages, or negative errno on failure > > to > > * Return > * ~~~~~~ > * Number of pages, or negative errno on failure > > If so, I oppose such an increase in verbosity and I think most others > would too. If not, please let me know what you're actually proposing ;-) Due to historical reasons, I think kernel-doc must handle a handful of special cases, as a preprocessor converting old conventions to rst. The title line, parameters, returns, and some in-line markup for &struct, etc. I'm not proposing changing "return:", because it's too widespread. I *am* questioning everything else that necessitates adding *more* special casing to handle things that would be easy to do in rst. I think we should be moving in the other direction, fixing things by removing special casing where we can. Case in point, "example:" as a section. Why should we be adding different ways of doing things in the documentation comments and the documentation files? Not having to do that was one of the original goals. Unify stuff to one markup. Make kernel-doc comments in source an extension to the documents under Documentation/. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center