linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: Dwaipayan Ray <dwaipayanray1@gmail.com>, mchehab@kernel.org
Cc: linux-kernel@vger.kernel.org, lukas.bulwahn@gmail.com,
	linux-doc@vger.kernel.org,
	Dwaipayan Ray <dwaipayanray1@gmail.com>
Subject: Re: [PATCH] docs: Add more message type documentations for checkpatch
Date: Thu, 20 May 2021 14:13:17 -0600	[thread overview]
Message-ID: <87k0ntnoyq.fsf@meer.lwn.net> (raw)
In-Reply-To: <20210515132348.19082-1-dwaipayanray1@gmail.com>

Dwaipayan Ray <dwaipayanray1@gmail.com> writes:

> - Document a couple of more checkpatch message types.
> - Add a blank line before all `See:` lines to improve the
>   rst output.
> - Create a new subsection `Permissions` and move a few types
>   to it.
>
> Signed-off-by: Dwaipayan Ray <dwaipayanray1@gmail.com>
> ---
>  Documentation/dev-tools/checkpatch.rst | 170 ++++++++++++++++++++++++-
>  1 file changed, 163 insertions(+), 7 deletions(-)

So this seems good, but I just notice something that has evidently
escaped me until now...

> diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst
> index 51fed1bd72ec..e409f27f48b6 100644
> --- a/Documentation/dev-tools/checkpatch.rst
> +++ b/Documentation/dev-tools/checkpatch.rst
> @@ -246,6 +246,7 @@ Allocation style
>      The first argument for kcalloc or kmalloc_array should be the
>      number of elements.  sizeof() as the first argument is generally
>      wrong.
> +
>      See: https://www.kernel.org/doc/html/latest/core-api/memory-allocation.html
>  
>    **ALLOC_SIZEOF_STRUCT**
> @@ -264,6 +265,7 @@ Allocation style
>    **ALLOC_WITH_MULTIPLY**
>      Prefer kmalloc_array/kcalloc over kmalloc/kzalloc with a
>      sizeof multiply.
> +
>      See: https://www.kernel.org/doc/html/latest/core-api/memory-allocation.html
>  
>  
> @@ -284,6 +286,7 @@ API usage
>      BUG() or BUG_ON() should be avoided totally.
>      Use WARN() and WARN_ON() instead, and handle the "impossible"
>      error condition as gracefully as possible.
> +
>      See: https://www.kernel.org/doc/html/latest/process/deprecated.html#bug-and-bug-on
>  
>    **CONSIDER_KSTRTO**
> @@ -292,12 +295,23 @@ API usage
>      may lead to unexpected results in callers.  The respective kstrtol(),
>      kstrtoll(), kstrtoul(), and kstrtoull() functions tend to be the
>      correct replacements.
> +
>      See: https://www.kernel.org/doc/html/latest/process/deprecated.html#simple-strtol-simple-strtoll-simple-strtoul-simple-strtoull
>  
> +  **IN_ATOMIC**
> +    in_atomic() is not for driver use so any such use is reported as an ERROR.
> +    Also in_atomic() is often used to determine if we may sleep, but it is not
> +    reliable in this use model therefore its use is strongly discouraged.
> +
> +    However, in_atomic() is ok for core kernel use.
> +
> +    See: https://lore.kernel.org/lkml/20080320201723.b87b3732.akpm@linux-foundation.org/
> +
>    **LOCKDEP**
>      The lockdep_no_validate class was added as a temporary measure to
>      prevent warnings on conversion of device->sem to device->mutex.
>      It should not be used for any other purpose.
> +
>      See: https://lore.kernel.org/lkml/1268959062.9440.467.camel@laptop/
>  
>    **MALFORMED_INCLUDE**
> @@ -308,11 +322,18 @@ API usage
>    **USE_LOCKDEP**
>      lockdep_assert_held() annotations should be preferred over
>      assertions based on spin_is_locked()
> +
>      See: https://www.kernel.org/doc/html/latest/locking/lockdep-design.html#annotations
>  
>    **UAPI_INCLUDE**
>      No #include statements in include/uapi should use a uapi/ path.
>  
> +  **USLEEP_RANGE**
> +    usleep_range() should be preferred over udelay(). The proper way of
> +    using usleep_range() is mentioned in the kernel docs.
> +
> +    See: https://www.kernel.org/doc/html/latest/timers/timers-howto.html#delays-information-on-the-various-kernel-delay-sleep-mechanisms

We really shouldn't be linking to outside sites - even kernel.org - when
referring to the kernel docs themselves.  Just say
"Documentation/timers/timers-howto" and let the build system handle the
links.

There's a lot of these in this file, alas...

I've applied this patch since it makes things better overall, but I
would really like to see all those URLs go away if possible.

Thanks,

jon

  parent reply	other threads:[~2021-05-20 20:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-15 13:23 [PATCH] docs: Add more message type documentations for checkpatch Dwaipayan Ray
2021-05-17 10:04 ` Lukas Bulwahn
2021-05-20 20:13 ` Jonathan Corbet [this message]
2021-05-20 20:33   ` Dwaipayan Ray
2021-05-20 20:45     ` Jonathan Corbet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k0ntnoyq.fsf@meer.lwn.net \
    --to=corbet@lwn.net \
    --cc=dwaipayanray1@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas.bulwahn@gmail.com \
    --cc=mchehab@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).