From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17C00C36010 for ; Sat, 5 Apr 2025 15:32:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8B8D26B0008; Sat, 5 Apr 2025 11:32:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 867DF6B000A; Sat, 5 Apr 2025 11:32:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 72F856B000C; Sat, 5 Apr 2025 11:32:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 5597E6B0008 for ; Sat, 5 Apr 2025 11:32:16 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 76BF61213BA for ; Sat, 5 Apr 2025 15:32:17 +0000 (UTC) X-FDA: 83300381514.12.7D53A43 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf27.hostedemail.com (Postfix) with ESMTP id A49B640005 for ; Sat, 5 Apr 2025 15:32:15 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=jVK6JF8R; spf=pass (imf27.hostedemail.com: domain of jic23@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=jic23@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743867135; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=fV5dHBpJfVmrE8DQ+hJRT9yCmP3MHqoqGuWkp/fak1I=; b=Jpr18xIF5/Yg3l793IC1P0TlpOs654wOSntT965F9MwMowkhJuvjAQ0UsO8B0xusX9HXLX RqYl/xI3/ax41qvSTrdNBt64V1Ib6+i55TiHuEFePuhUvquJcSC2A7gQB2b9m6QULyi1D7 pmrqkic2Su4cCzyQs0CxDPCfQiQDqYc= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=jVK6JF8R; spf=pass (imf27.hostedemail.com: domain of jic23@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=jic23@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743867135; a=rsa-sha256; cv=none; b=C2Abh2yrZq1E9Agb8jKcDQmNtFAP+Jie7UsPF9FeeAhTJI74+79ekaKwXRrg2EamTJXmOA 4X+f3xCWEIb72xj4wUqkZmCTtzlG1UObLYgfG+d/ukKXJ8l34dztUW9A1PjdK5H2QbcZwK YxOXjFlmDE0VhPMs/35f2e+iy9xVtAw= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 8812443BC0; Sat, 5 Apr 2025 15:32:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 23B8AC4CEE4; Sat, 5 Apr 2025 15:32:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1743867134; bh=RdPSb3R/N8g0+oYT6+2V0LNQyAZKsrTfROQEnTne+ak=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=jVK6JF8RzIa2fTbodJS2FISwWudNboXPBdoMoty0m2mNay6iJThuDSiveMToI7V8O 6g42eS8E8LtVI1QtvaMdw0SCKHNRCfLy0HhQZ9huqFtTKXXYLeE0vgxLVvbbhyeWV9 /2AcgLtXGwCv+ZtdoJsPxpFgNHty72ixEgcls3MiRRT57BMJNjgXWrqquPIHsgUjWo Xrc3yG2qtgjXemyHrcmVgYcq10cFR7TTNYhQzl+nTvdm+Ef7qp75wk6UO/6XQFrscS v1OjaKgVM6dR70zKrI+gtG7dOiGVaMpbieSrkNOSwc3LpO/u9ElY/UEveU82g3GLiz NgnIiJ3gmDWxw== Date: Sat, 5 Apr 2025 16:31:58 +0100 From: Jonathan Cameron To: Jonathan Corbet Cc: Jonathan Cameron , "=?UTF-8?B?TsOtY29s?= =?UTF-8?B?YXM=?= F. R. A. Prado" , Andrew Morton , Vinod Koul , Eric Biggers , "Theodore Y. Ts'o" , Jaegeuk Kim , Lars-Peter Clausen , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Maxime Chevallier , James Bottomley , Jarkko Sakkinen , Mimi Zohar , Jaroslav Kysela , Takashi Iwai , Mauro Carvalho Chehab , Richard Weinberger , Anton Ivanov , Johannes Berg , kernel@collabora.com, linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-iio@vger.kernel.org, netdev@vger.kernel.org, workflows@vger.kernel.org, linux-integrity@vger.kernel.org, keyrings@vger.kernel.org, linux-sound@vger.kernel.org, linux-media@vger.kernel.org, linux-um@lists.infradead.org Subject: Re: [PATCH] docs: Remove literal markup from Documentation/ paths Message-ID: <20250405163158.55935fdf@jic23-huawei> In-Reply-To: <874iz3g6w1.fsf@trenco.lwn.net> References: <20250404-doc-paths-unliteral-v1-1-74718785444e@collabora.com> <20250404182006.000038cc@huawei.com> <874iz3g6w1.fsf@trenco.lwn.net> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.48; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: A49B640005 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 5f4z36ks74ppeiuhb73ahi7qdcg3z3xd X-HE-Tag: 1743867135-15568 X-HE-Meta: U2FsdGVkX194YZnbsmf01gF/DEsLbvPHozsCJMCpBPCC0h0EekyqvK/ucKSW0FpI32ewuCYrzvSvAmhPszqnRhqfjPb5N98pPz+N6lQfV39syC+xEW4X9A+5/40tOgb0P8e6T96ART/yGwyRkWzhB4sJFbC7hhOXsqtpa/vCSH0sl9nT7gkxeV5qhKFum6gnUD0Tt05A1093KS1nTCupTeSXjwWT4S/tYlTO3j/TZGNs/Idb1FOLPsqvqTje+7Od+3Kr5GbJmAtJlEGJq9O3vcMbgmdGrSYYz/qXahdgSCBrVcBr+qljr+3eQJMEq3juC3lVP0sqBJfLHnkEHPnrL3b3w5zjuRPZdHJtoLt4gJU3/yzuME44E8W72WXGaRdgMg01/ydEWPVtrtsqp99tMeQ0o30HSG37ftntcxidT5u9G+KeR6sgkUsYcVhtcJ4Jd6Y7gJAA+CCYDwr1zmBrAJFcjpHGaymskJf2P4km6+YaSiRNtImn6QvBHVgsgoKz3ghGobQ9WPEsPcUinZ5nnn5kmbtJtoBM319PloHBOMvXW69lCMaH6qRp0UtZiHkin3JPk+oE3ZdDk+Fn8oZBX+xTy8Xs+bXtj8Hg73gTLaXxF8b+ESDlWEGuFnBBjih06c2MDYlezL+8KOvKRpyQIez+P9TIDNqX46G634DPySQSLrPBqWRz/Tt195hNrHeboVmAK6ixrPsw6jWGoTciaa5NnwKrlHBLkud89xTOX17EyNEKHoH+vQveEGJzg4gGurntL29BlQgLgKPfNuImZTws7+UbntFwWeHusDMOYODTHrJVqcZE6dhudZ9NUSWCp3KsTHDOtxjMFDrtCR6WRB9fDkhxg7heV1LrF3ZvCO3+Ct+L8uTAoWCtIP+vZHN7uT/dcrEXwwSoxjyWrheko8o8QSGTgWSyr1ZT8jwk9rNZRPXSELL86QwA+211VtTDDmS4DwjajkodhLkYTb7 615B+6rS KmXyiQ9mXWtfMdV0rDQoHXqAmAFstRltsm0SmbWZ10e3G2XOhonTwVXlcgShr7nonl94RRgkAfv2hG7C6TcIdLeyUe4iGnVfuURpd2n5KTAVIK/THrTDDm3gu5whFrHlZahIUI2MktGgVooEB8JCvxqgUKQ0mPnq2I+yNpemnI45TbUEmqTjfiw5uZ9RGPqr9dwBdQUcWHxlYCcwjGJhDc82q+V5vccLR6ceKdQMlUKtWaiGikyclEqQ4m3AuzYQgTSmPI+kVSvxRUbFCZP8QPFxmeZtrvriyPZ+eZKnwkbdzbizFreWhs6vB5Sk7B2ojX7dPtdm47LvTAw583WglnqEV5ohx5yuWRx8Kuwpmr7Jg2z4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, 04 Apr 2025 11:42:54 -0600 Jonathan Corbet wrote: > Jonathan Cameron writes: >=20 > > On Fri, 04 Apr 2025 11:37:28 -0400 > > N=C3=ADcolas F. R. A. Prado wrote: > > =20 > >> Given that the automarkup Sphinx plugin cross-references > >> "Documentation/*.rst" strings in the text to the corresponding > >> documents, surrounding those strings with the literal markup (``) not > >> only adds unnecessary markup in the source files, but actually prevents > >> the automatic cross-referencing to happen (as it doesn't happen in > >> literal blocks). > >>=20 > >> Remove all the occurrences of the literal markup in > >> "Documentation/*.rst" paths, except when the actual source file is bei= ng > >> referred. Also change the surrounding text when needed so it reads well > >> both in the source and the web page (eg. 'see file Doc...' -> 'see > >> Doc...'). > >>=20 > >> Signed-off-by: N=C3=ADcolas F. R. A. Prado > >> --- > >> Documentation/admin-guide/mm/numa_memory_policy.rst | 2 +- > >> Documentation/admin-guide/serial-console.rst | 2 +- > >> Documentation/driver-api/dmaengine/client.rst | 2 +- > >> Documentation/driver-api/nvdimm/security.rst | 2 +- > >> Documentation/filesystems/fscrypt.rst | 4 ++-- > >> Documentation/iio/adis16475.rst | 4 ++-- > >> Documentation/iio/adis16480.rst | 4 ++-- > >> Documentation/iio/adis16550.rst | 4 ++-- > >> Documentation/iio/adxl380.rst | 4 ++-- =20 > > > > Split patch up by subsystem would be a good thing here as we may > > get other changes to these docs during the cycle and resulting > > merge conflicts if this all goes in as one patch. =20 >=20 > That seems like a way to add a significant amount of pain to a basic > (but indeed useful) cleanup patch like this. If the relevant > maintainers insist on it then that's how it has to be done, but I bet I > could just take the whole thing through docs with almost no trouble. >=20 hmm. I'll go with maybe. Let's cross fingers then. Acked-by: Jonathan Cameron > jon