Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp534733pxu; Tue, 6 Oct 2020 12:22:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxdH1YM8GzSDwd09qWJq0XkrRfv7zEdXdHDKMvk52U6qMV7k97gEXQ9fJCqonZCVb/xSDH4 X-Received: by 2002:aa7:c9ce:: with SMTP id i14mr7020139edt.279.1602012125105; Tue, 06 Oct 2020 12:22:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602012125; cv=none; d=google.com; s=arc-20160816; b=gL1ciQ0R/kWSOn8g7k2lPLZM8E22TuLHHcSwbyruCGYrHB0ovebfbZavySgrXWF8N1 EIgFeBvOAo+mhCyRREZAY04eieFWG1JOwecB7z7mELmEP6qK4N55Coa2Lwl0m6nsiORD PChK8va5UDZsO3+FJRdMzgXE/TiP8QMRQYVw1GyV/M0XlSWq5sBY8f7o86ibqLD0eOFV FDkAIhtvG5j0pgGrH3SJKHBWOcHYsF9xbP+qlvxbHs+6uaWDEHa40O356IqDdGLSY+4e OWh4jpKOkOz+KKhEH4JUlVsBB51lT59C7dWqw59T0OVGc2CsJbdhvWTj0h3F6K97jMW1 /7mA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=wfJVG70JotS1c+G6dS2agp4Gd/25GsMVT/VLwPFJJ4E=; b=x/2rocpyZriDGxfAcLejHWeg49B87p34sXZiB+OUH49jgtU/GIKDAUYYMNncctZtuF uE/d5B7j0z6xs5O1ndqEYDS9qApU7Mf5M1St9rsLdwTDF82juiYLvNJuvFDIbGBifjJI ze1rzDVVp6sF7NuDHZCgiljTpgkhzunbqidcBZQZQDDDzODWOZoXi+MptNxQnV+5ZcHH dKrEoadX9ncuOd7OXzdPEnJH7dqZDMz4ztBkcSzdhxXpB53/73QVlpb9VVhqE2531GiZ 7nSRFQkSr6KEAnpvDxRu2KWobct3qSUUDE/46frofxYeZUHw4oaRR9cOAsgUGeCy9R+t BihA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Mv5ki+7+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c11si3061917edj.596.2020.10.06.12.21.40; Tue, 06 Oct 2020 12:22:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Mv5ki+7+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727068AbgJFTT4 (ORCPT + 99 others); Tue, 6 Oct 2020 15:19:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:52316 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727005AbgJFTT4 (ORCPT ); Tue, 6 Oct 2020 15:19:56 -0400 Received: from gmail.com (unknown [104.132.1.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0C248206B5; Tue, 6 Oct 2020 19:19:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602011995; bh=ov/h1Xqg0UOCJfEEBRiRrL5VVBUq6at/su2wB3rWscM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Mv5ki+7+ByDNKqS4mIXj0C7OTINtnjK0tQS7WQEfhuUfGHOz+yn0F1TlQ1dJtBVea Wh4KnR0E5VZKb2rHxtjQXSP/mnp7LAu6u2upjfVcO6k2bhJ0+bfifkCRUKcx3LzHmj BMpoDxNUlmGjtOGePIZnuAT/Q62E7pN62cuc1V9Q= Date: Tue, 6 Oct 2020 12:19:53 -0700 From: Eric Biggers To: Mauro Carvalho Chehab Cc: Linux Doc Mailing List , Jonathan Corbet , "Theodore Y. Ts'o" , Jaegeuk Kim , linux-fscrypt@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 35/52] docs: fs: fscrypt.rst: get rid of :c:type: tags Message-ID: <20201006191953.GA3598358@gmail.com> References: <81cd5da550e06de8e85dcadef4909ff5f1d23319.1601992016.git.mchehab+huawei@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <81cd5da550e06de8e85dcadef4909ff5f1d23319.1601992016.git.mchehab+huawei@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 06, 2020 at 04:03:32PM +0200, Mauro Carvalho Chehab wrote: > The :c:type: tag has problems with Sphinx 3.x, as structs > there should be declared with c:struct. > > So, remove them, relying at automarkup.py extension to > convert them into cross-references. I tried 'make htmldocs' before and after your patchset ("sphinx3-fixes-v5"). Before, all the struct fscrypt_* are rendered in code font. After, they are rendered in the regular text font. Is that really working as intended? > > Signed-off-by: Mauro Carvalho Chehab > --- > Documentation/filesystems/fscrypt.rst | 51 ++++++++++++--------------- > 1 file changed, 23 insertions(+), 28 deletions(-) > Why are the changes to fscrypt.rst split between two patches, docs: get rid of :c:type explicit declarations for structs and docs: fs: fscrypt.rst: get rid of :c:type: tags ? They're the same type of changes. The first just removes half the :c:type: tags, and the second removes the rest. Shouldn't it be one patch? > diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst > index 4f858b38a412..46a9d1bd2ab5 100644 > --- a/Documentation/filesystems/fscrypt.rst > +++ b/Documentation/filesystems/fscrypt.rst > @@ -437,8 +437,7 @@ FS_IOC_SET_ENCRYPTION_POLICY > The FS_IOC_SET_ENCRYPTION_POLICY ioctl sets an encryption policy on an > empty directory or verifies that a directory or regular file already > has the specified encryption policy. It takes in a pointer to a > -struct fscrypt_policy_v1 or a :c:type:`struct > -fscrypt_policy_v2`, defined as follows:: > +struct fscrypt_policy_v1 or a struct fscrypt_policy_v2, defined as follows:: [...] > If the file is not yet encrypted, then FS_IOC_SET_ENCRYPTION_POLICY > verifies that the file is an empty directory. If so, the specified > @@ -637,9 +634,8 @@ The FS_IOC_GET_ENCRYPTION_POLICY ioctl can also retrieve the > encryption policy, if any, for a directory or regular file. However, > unlike `FS_IOC_GET_ENCRYPTION_POLICY_EX`_, > FS_IOC_GET_ENCRYPTION_POLICY only supports the original policy > -version. It takes in a pointer directly to a :c:type:`struct > -fscrypt_policy_v1` rather than a :c:type:`struct > -fscrypt_get_policy_ex_arg`. > +version. It takes in a pointer directly to struct fscrypt_policy_v1 > +rather than struct fscrypt_get_policy_ex_arg. In some cases you deleted the "a" in "a struct" but in other cases you didn't. Intentional? It seems the file should consistently use one style or the other. Also please use textwidth=70 for consistency with the rest of the file. - Eric