From: Greg KH <gregkh@linuxfoundation.org>
To: Gabriele Paoloni <gpaoloni@redhat.com>
Cc: corbet@lwn.net, skhan@linuxfoundation.org, arnd@arndb.de,
brendan.higgins@linux.dev, raemoar63@gmail.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com,
acarminati@nvidia.com, linux-mm@kvack.org,
safety-architecture@lists.elisa.tech,
kstewart@linuxfoundation.org, chuckwolber@gmail.com
Subject: Re: [RFC PATCH v3 1/6] Documentation: extend the 'Function documentation' with expected behavior and constraints of use
Date: Thu, 12 Feb 2026 13:59:06 +0100 [thread overview]
Message-ID: <2026021221-grading-clatter-b7bf@gregkh> (raw)
In-Reply-To: <20260212124923.222484-2-gpaoloni@redhat.com>
On Thu, Feb 12, 2026 at 01:49:18PM +0100, Gabriele Paoloni wrote:
> Extend the longer description section of a function kernel-doc
> header with an itemised list of function's behaviors and
> constraints of use.
> These are useful to link and trace test cases (e.g. KUnit) to
> the different behavior IDs and define the constraints to be
> met by the function's caller.
>
> Signed-off-by: Gabriele Paoloni <gpaoloni@redhat.com>
> ---
> Documentation/doc-guide/kernel-doc.rst | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/Documentation/doc-guide/kernel-doc.rst b/Documentation/doc-guide/kernel-doc.rst
> index 8d2c09fb36e4..23e6c4b45b14 100644
> --- a/Documentation/doc-guide/kernel-doc.rst
> +++ b/Documentation/doc-guide/kernel-doc.rst
> @@ -83,6 +83,25 @@ The general format of a function and function-like macro kernel-doc comment is::
> *
> * The longer description may have multiple paragraphs.
> *
> + * When specifying testable code behaviour the longer description must contain
> + * a paragraph formatted as follows:
> + *
> + * function_name behavior:
> + * [ID1] - [expected behavior]
> + *
> + * [ID2] - [expected behavior]
> + *
> + * [...]
> + *
> + * [IDn] - [expected behavior]
> + *
> + * function_name constraints of use:
> + * [ID1] - [constraint to be met by the caller]
> + *
> + * [ID2] - [constraint to be met by the caller]
> + *
> + * [IDn] - [constraint to be met by the caller]
So the same "id" is used for a behavior, AND a constraint?
And what defines an "id"? I see in your example you use number.number,
but is that specified?
And how is a id going to stay in sync across different files? That
feels impossible to maintain for any length of time, and puts a burden
on the developer who wishes to add/remove a test or "id", AND a
maintainer who has to remember to go and look in multiple places for
such an id sync up.
That's just not going to work, sorry.
greg k-h
next prev parent reply other threads:[~2026-02-12 12:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-12 12:49 [RFC PATCH v3 0/6] some /dev/mem specifications and traced testing Gabriele Paoloni
2026-02-12 12:49 ` [RFC PATCH v3 1/6] Documentation: extend the 'Function documentation' with expected behavior and constraints of use Gabriele Paoloni
2026-02-12 12:59 ` Greg KH [this message]
2026-02-12 14:00 ` Gabriele Paoloni
2026-02-12 15:23 ` Greg KH
2026-02-13 17:13 ` Gabriele Paoloni
2026-02-12 12:49 ` [RFC PATCH v3 2/6] /dev/mem: Add initial documentation of memory_open() and mem_fops Gabriele Paoloni
2026-02-12 12:49 ` [RFC PATCH v3 3/6] kunit: add visibility helpers for static inline functions Gabriele Paoloni
2026-02-12 12:49 ` [RFC PATCH v3 4/6] char: mem: expose devmem helpers for KUnit testing Gabriele Paoloni
2026-02-12 12:49 ` [RFC PATCH v3 5/6] char: mem: add KUnit tests for /dev/mem read_mem() Gabriele Paoloni
2026-02-12 12:49 ` [RFC PATCH v3 6/6] char: mem: add Kconfig option for devmem KUnit tests Gabriele Paoloni
2026-02-14 1:03 ` kernel test robot
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=2026021221-grading-clatter-b7bf@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=acarminati@nvidia.com \
--cc=arnd@arndb.de \
--cc=brendan.higgins@linux.dev \
--cc=chuckwolber@gmail.com \
--cc=corbet@lwn.net \
--cc=gpaoloni@redhat.com \
--cc=kstewart@linuxfoundation.org \
--cc=kunit-dev@googlegroups.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=raemoar63@gmail.com \
--cc=safety-architecture@lists.elisa.tech \
--cc=skhan@linuxfoundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.