linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Gabriele Paoloni <gpaoloni@redhat.com>
To: corbet@lwn.net, skhan@linuxfoundation.org, arnd@arndb.de,
	gregkh@linuxfoundation.org, 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
Cc: acarminati@nvidia.com, linux-mm@kvack.org,
	safety-architecture@lists.elisa.tech,
	kstewart@linuxfoundation.org, chuckwolber@gmail.com,
	gpaoloni@redhat.com
Subject: [RFC PATCH v3 0/6] some /dev/mem specifications and traced testing
Date: Thu, 12 Feb 2026 13:49:17 +0100	[thread overview]
Message-ID: <20260212124923.222484-1-gpaoloni@redhat.com> (raw)

RFCv1 [1] was an initial proposal defining testable code specifications for
some functions in /drivers/char/mem.c. However it was not clear how to
write specifications according to the format and wording used for them, plus
tests were missing.

RFCv2 [2] proposed a guideline explaining how to write such testable code
specifications and also added kselftest for read_mem, however there was
reluctance to accept the proposed addition before having clarity on who needs
it, who is going to maintain it and for which APIs in the kernel it is
needed.

RFCv3 (this one) proposes kernel-doc API documentation according to the
current doc-guide for some APIs of /dev/mem introducing the concept of
traceable specifications to KUnit tests.
For read_mem() Kunit tests traced to the corresponding specifications
are also introduced, so that in case of test failure it is clear which
specification is violated and it would be easier to review incoming
patches agaisnt the intended behavior of the code.

[1] https://lore.kernel.org/all/20250821170419.70668-1-gpaoloni@redhat.com/
[2] https://lore.kernel.org/all/20250910170000.6475-1-gpaoloni@redhat.com/

Alessandro Carminati (4):
  kunit: add visibility helpers for static inline functions
  char: mem: expose devmem helpers for KUnit testing
  char: mem: add KUnit tests for /dev/mem read_mem()
  char: mem: add Kconfig option for devmem KUnit tests

Gabriele Paoloni (2):
  Documentation: extend the 'Function documentation' with expected
    behavior and constraints of use
  /dev/mem: Add initial documentation of memory_open() and mem_fops

 Documentation/doc-guide/kernel-doc.rst |   19 +
 drivers/char/Kconfig                   |   21 +
 drivers/char/Makefile                  |    1 +
 drivers/char/mem.c                     |  211 +++-
 drivers/char/mem.h                     |   17 +
 drivers/char/mem_kunit_test.c          | 1323 ++++++++++++++++++++++++
 include/kunit/visibility.h             |    2 +
 7 files changed, 1584 insertions(+), 10 deletions(-)
 create mode 100644 drivers/char/mem.h
 create mode 100644 drivers/char/mem_kunit_test.c

-- 
2.48.1



             reply	other threads:[~2026-02-12 12:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-12 12:49 Gabriele Paoloni [this message]
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
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

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=20260212124923.222484-1-gpaoloni@redhat.com \
    --to=gpaoloni@redhat.com \
    --cc=acarminati@nvidia.com \
    --cc=arnd@arndb.de \
    --cc=brendan.higgins@linux.dev \
    --cc=chuckwolber@gmail.com \
    --cc=corbet@lwn.net \
    --cc=gregkh@linuxfoundation.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox