Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp8771ybl; Wed, 11 Dec 2019 13:06:58 -0800 (PST) X-Google-Smtp-Source: APXvYqwAOhFaBMKDzLdZiBLA+aashkjUZHsb1e5qqufWwJ0AW4dMVZqt9vJz25Zjnoxgd8sAIrR1 X-Received: by 2002:a05:6830:14c7:: with SMTP id t7mr4069855otq.72.1576098418415; Wed, 11 Dec 2019 13:06:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576098418; cv=none; d=google.com; s=arc-20160816; b=LeBVyD3zF7Ta+A0dlIy0fNCwP4lnh+xbgcW5/9oIAt2Z9r+6iOgMOqC0xFSZdhiVwL 3iCIgzUn7h5dFiuUKMPm5sfX2gK2YPvUGOHqWzCKKv+Fj7ytORWc7hx4PuXLAOZl/0dP 3DudV7WpNdYWB9jtxuw4JFVKQK25rZ3VVk/13ZSfItGtN4wJ+fc2u/XiZ3HiXXnQLbMy yjEi292jMGpjokD65J9yFfiVp7SqMl6mJi2Aye9FoFq+R/FElZMSU4FLZLmviooEq+tu 7IBIq5zePrlBj7CQFVj08kvR4pBNvFwnSupNaMv7JoAOG9XChKDNBe2R4agmqBmYIAxw ds8Q== 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=KxLHd/t03I7uJx0bl0SlxAm5iTD+rppvHFNeZhqXqw4=; b=qRdugN+TLqkTZ0iDz1WYV/XVxXEmtVRS2X/Ts5jBLIgYaG4wCdDIHUR+blw06hQORx hwi7HHcecqETx/yBkub2QBZd9+QLX4Aw5gELlcY+jB3EB9p49fz4cPRWStfD51KG/jE5 jcFmanIF+01rtKOYUDkbkihLqyB9y64nHxT1bc3IGmilbcSR5xPyAeBToHGguPWE5Fi7 1SX65cjL433ou3m//jLeU49ulM/CtxS/usaUDQr9N/u4cbDw5LuAbd8aIZ597ShmyAYx +QgYrk8Y4FeMEBWPToX+rFoWBvL9nkyXZ95VyHxRZl0SBrc2ZVY2eQ6me/yDB3hxptu2 CQ1g== 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 f20si1650036oti.123.2019.12.11.13.06.26; Wed, 11 Dec 2019 13:06:58 -0800 (PST) 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 S1726518AbfLKVFx (ORCPT + 99 others); Wed, 11 Dec 2019 16:05:53 -0500 Received: from ms.lwn.net ([45.79.88.28]:58294 "EHLO ms.lwn.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726141AbfLKVFx (ORCPT ); Wed, 11 Dec 2019 16:05:53 -0500 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 603E97DF; Wed, 11 Dec 2019 21:05:52 +0000 (UTC) Date: Wed, 11 Dec 2019 14:05:51 -0700 From: Jonathan Corbet To: Arnd Bergmann Cc: Jens Axboe , "James E.J. Bottomley" , "Martin K. Petersen" , Alexander Viro , linux-kernel@vger.kernel.org, y2038@lists.linaro.org, Mauro Carvalho Chehab , Jonathan =?UTF-8?B?TmV1c2Now6RmZXI=?= , Masahiro Yamada , Vladimir Oltean , Kent Overstreet , linux-doc@vger.kernel.org Subject: Re: [PATCH 24/24] Documentation: document ioctl interfaces better Message-ID: <20191211140551.00520269@lwn.net> In-Reply-To: <20191211204306.1207817-25-arnd@arndb.de> References: <20191211204306.1207817-1-arnd@arndb.de> <20191211204306.1207817-25-arnd@arndb.de> 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, 11 Dec 2019 21:42:58 +0100 Arnd Bergmann wrote: > Documentation/process/botching-up-ioctls.rst was orignally > written as a blog post for DRM driver writers, so it it misses > some points while going into a lot of detail on others. > > Try to provide a replacement that addresses typical issues > across a wider range of subsystems, and follows the style of > the core-api documentation better. > > Signed-off-by: Arnd Bergmann Thanks for improving the docs! I have a few nits outside of the content itself. > Documentation/core-api/index.rst | 1 + > Documentation/core-api/ioctl.rst | 250 +++++++++++++++++++++++++++++++ > 2 files changed, 251 insertions(+) > create mode 100644 Documentation/core-api/ioctl.rst So you left the old document in place; was that intentional? > diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst > index ab0eae1c153a..3f28b2f668be 100644 > --- a/Documentation/core-api/index.rst > +++ b/Documentation/core-api/index.rst > @@ -39,6 +39,7 @@ Core utilities > ../RCU/index > gcc-plugins > symbol-namespaces > + ioctl > > > Interfaces for kernel debugging > diff --git a/Documentation/core-api/ioctl.rst b/Documentation/core-api/ioctl.rst > new file mode 100644 > index 000000000000..cb2c86ae63e7 > --- /dev/null > +++ b/Documentation/core-api/ioctl.rst > @@ -0,0 +1,250 @@ > +====================== > +ioctl based interfaces > +====================== > + > +:c:func:`ioctl` is the most common way for applications to interface Please don't use :c:func: anymore. If you just say "ioctl()" the right thing will happen (which is nothing here, since there isn't anything that makes sense to link to in the internal kernel context). We need a checkpatch rule for :c:func: I guess. Similarly, later on you have: > +Timeout values and timestamps should ideally use CLOCK_MONOTONIC time, > +as returned by ``ktime_get_ns()`` or ``ktime_get_ts64()``. Unlike > +CLOCK_REALTIME, this makes the timestamps immune from jumping backwards > +or forwards due to leap second adjustments and clock_settime() calls. Making those functions ``literal`` will defeat the automatic cross-referencing. Better to just say ktime_get_ns() without quotes. [...] > +* On the x86-32 (i386) architecture, the alignment of 64-bit variables > + is only 32 bit, but they are naturally aligned on most other > + architectures including x86-64. This means a structure like > + > + :: You don't need the extra lines here; just say "...a structure like::" > + struct foo { > + __u32 a; > + __u64 b; > + __u32 c; > + }; > + Thanks, jon