Re: [PATCH] docs: Add more message type documentations for checkpatch

Dwaipayan Ray
2021-05-20T20:33:48Z

(Adding Joe for comments)

On Fri, May 21, 2021 at 1:43 AM Jonathan Corbet <corbet@lwn.net> wrote:
>
> 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 Jonathan.

Yes it might make things better for the documentation, but again
since we are using these descriptions in checkpatch's --verbose mode,
we shall lose the ability to show the links there which I think is currently
a good addition for the end user.

And I don't think there will be a way to generate these links in checkpatch
without sphinx's build system....

Are there any alternatives?

Also Joe, any comments here?

Thanks,
Dwaipayan.

> Thanks,
>
> jon