Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp1628ybi; Wed, 29 May 2019 15:32:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqwD0O7qhiy/T89MFyGBHZrivQtrnVCnUSnZbUSwIXyegV3L9T3QGOn6NUT/v6OTQW+9ZjuB X-Received: by 2002:a17:902:f208:: with SMTP id gn8mr334702plb.312.1559169146160; Wed, 29 May 2019 15:32:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559169146; cv=none; d=google.com; s=arc-20160816; b=s98dO7oTwszYgxv4NxGq46Qnxr2/zi2/YouQdOiydyYTYZpfyN8FYrnT9x06yTnFv3 sGsXVQ8gdOBxwHzhT6Mzmo66kqZwh0WH/evyzJeFxg5srBS8RI9kZsuFIT1t+Qc4DaRT cGuFVT8MB+6SM2z5K34Cu8FuWOOwnq0t0ErVI/DK2aJtGIzIiSi9s1EC1xhpCroZpVXY svffUyjhQvPJBKM44Si4kITsz8aHPmgDjOlOgf+emZgngfganB9dVch9UNIB4y3iLbE/ BGmX9mo9Cx7mYU+VK95Z0h/woaz2Vis5ctB2XQVfyhW8QIvt32Y4YBc+kkbWyVPPH1NY j28A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=q14F9cjTyRmKsxy4uCDZTJqmili52w+zXQA7beJR6dE=; b=VIrkb9sEiu7Ce59Ml0dgoTlVPNMNXF2cqCnJ4M64K8tecj5HYtc1cMy8S0EXh1blZT scxfxlGKuJGMP7sWUveIuWhvOrz5q4aSeqZndnZRy/AQKG+SlTsxDGWYUbDS64zpKO5J hKANdQ8G0H2HxTuAYXcs5wYD+OFePVtBnDUUdbVsc+cvhaJwbvVUH7OhwlxbRCbr5Qhl ClsbuwFF0IGAak8/UN6MvlBpZfXu1gCHIKYmREKGK5oHt171HGvXlcKZdy+SEzZAG6mQ /Ee1FnfLE7f6W6GvaAayOlPCTvpvCRKuk07bmxu8O7/XxySs1mcw4GPYGkIEkqaVfzh9 q9ig== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b15si982849pgl.583.2019.05.29.15.32.09; Wed, 29 May 2019 15:32:26 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726610AbfE2Way (ORCPT + 99 others); Wed, 29 May 2019 18:30:54 -0400 Received: from ms.lwn.net ([45.79.88.28]:43864 "EHLO ms.lwn.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726018AbfE2Way (ORCPT ); Wed, 29 May 2019 18:30:54 -0400 Received: from lwn.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id 6ECC660C; Wed, 29 May 2019 22:30:53 +0000 (UTC) Date: Wed, 29 May 2019 16:30:52 -0600 From: Jonathan Corbet To: "Tobin C. Harding" Cc: Al Viro , Mauro Carvalho Chehab , Neil Brown , Randy Dunlap , linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 0/9] docs: Convert VFS doc to RST Message-ID: <20190529163052.6ce91581@lwn.net> In-Reply-To: <20190515002913.12586-1-tobin@kernel.org> References: <20190515002913.12586-1-tobin@kernel.org> Organization: LWN.net MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 15 May 2019 10:29:04 +1000 "Tobin C. Harding" wrote: > Here is an updated version of the VFS doc conversion. This series in no > way represents a final point for the VFS documentation rather it is a > small step towards getting VFS docs updated. This series does not > update the content of vfs.txt, only does formatting. I've finally gotten to this, sorry for taking so long. Applying it to docs-next turned out to be a bit of a chore; there have been intervening changes to vfs.txt that we didn't want to lose. But I did it. Unfortunately, there's still a remaining issue. You did a lot of list conversions like this: > - struct file_system_type *fs_type: describes the filesystem, partly initialized > +``struct file_system_type *fs_type``: describes the filesystem, partly initialized > by the specific filesystem code but that does not render the way you would like, trust me. You really want to use the list format, something like: ``struct file_system_type *fs_type`` describes the filesystem, partly initialized by the specific filesystem code There are, unfortunately, a lot of these to fix... I bet it could be done with an elisp function, but I don't have time to beat my head against that wall right now. Any chance you would have time to send me a followup patch fixing these up? I'll keep my branch with this set for now so there's no need to rebase those. Thanks, jon