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

[Dwaipayan Ray]

(Adding Joe for comments)

On Fri, May 21, 2021 at 1:43 AM Jonathan Corbet <corbet@xxxxxxx> wrote:
>
> Dwaipayan Ray <dwaipayanray1@xxxxxxxxx> 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@xxxxxxxxx>
> > ---
> >  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@xxxxxxxxxxxxxxxxxxxx/
> > +
> >    **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