linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Gabriele Paoloni <gpaoloni@redhat.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: shuah@kernel.org, linux-kselftest@vger.kernel.org,
	 linux-kernel@vger.kernel.org, corbet@lwn.net,
	linux-doc@vger.kernel.org,  linux-mm@kvack.org,
	safety-architecture@lists.elisa.tech, acarmina@redhat.com,
	 kstewart@linuxfoundation.org, chuckwolber@gmail.com
Subject: Re: [RFC PATCH v2 0/3] Add testable code specifications
Date: Tue, 21 Oct 2025 11:42:24 +0200	[thread overview]
Message-ID: <CA+wEVJZEho_9kvaGYstc=5f6iHGi69x=_0zT+jrC2EqSFUQMWQ@mail.gmail.com> (raw)
In-Reply-To: <2025102111-facility-dismay-322e@gregkh>

Hi Greg

On Tue, Oct 21, 2025 at 9:35 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Sep 10, 2025 at 06:59:57PM +0200, Gabriele Paoloni wrote:
> > [1] was an initial proposal defining testable code specifications for
> > some functions in /drivers/char/mem.c.
> > However a Guideline to write such specifications was missing and test
> > cases tracing to such specifications were missing.
> > This patchset represents a next step and is organised as follows:
> > - patch 1/3 contains the Guideline for writing code specifications
> > - patch 2/3 contains examples of code specfications defined for some
> >   functions of drivers/char/mem.c
> > - patch 3/3 contains examples of selftests that map to some code
> >   specifications of patch 2/3
> >
> > [1] https://lore.kernel.org/all/20250821170419.70668-1-gpaoloni@redhat.com/
>
> "RFC" implies there is a request.  I don't see that here, am I missing
> that?  Or is this "good to go" and want us to seriously consider
> accepting this?

I assumed that an RFC (as in request for comments) that comes with proposed
changes to upstream files would be interpreted as a request for feedbacks
associated with the proposed changes (what is wrong or what is missing);
next time I will communicate the request explicitly.

WRT this specific patchset, the intent is to introduce formalism in specifying
code behavior (so that the same formalism can also be used to write and
review test cases), so my high level asks would be:

1) In the first part of patch 1/3 we explain why we are doing this and the high
level goals. Do you agree with these? Are these clear?

2) In the rest of the patchset we introduce the formalism, we propose some
specs (in patch 2) and associated selftests (in patch 3). Please let us know
if there is something wrong, missing or to be improved.

Thanks and kind regards
Gab

>
> thanks,
>
> greg k-h
>



  reply	other threads:[~2025-10-21  9:42 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-10 16:59 Gabriele Paoloni
2025-09-10 16:59 ` [RFC v2 PATCH 1/3] Documentation: add guidelines for writing " Gabriele Paoloni
2025-09-15 22:33   ` Jonathan Corbet
2025-09-17 15:24     ` Gabriele Paoloni
2025-10-20 19:35     ` David Hildenbrand
2025-10-20 20:54       ` Chuck Wolber
2025-10-20 21:02       ` Chuck Wolber
2025-10-21 15:37         ` David Hildenbrand
2025-10-21 16:27           ` Gabriele Paoloni
2025-10-21 16:34             ` David Hildenbrand
2025-10-21 16:43               ` Gabriele Paoloni
2025-09-10 16:59 ` [RFC v2 PATCH 2/3] /dev/mem: Add initial documentation of memory_open() and mem_fops Gabriele Paoloni
2025-09-15 22:39   ` Jonathan Corbet
2025-09-16  7:29     ` Chuck Wolber
2025-09-17 15:38     ` Gabriele Paoloni
2025-09-10 17:00 ` [RFC v2 PATCH 3/3] selftests/devmem: initial testset Gabriele Paoloni
2025-10-21  7:35   ` Greg KH
2025-10-21 17:40     ` Alessandro Carminati
2025-10-21  7:35 ` [RFC PATCH v2 0/3] Add testable code specifications Greg KH
2025-10-21  9:42   ` Gabriele Paoloni [this message]
2025-10-21 16:46     ` Greg KH
2025-10-22 14:06       ` Gabriele Paoloni
2025-10-22 17:13         ` Greg KH
2025-11-07 16:29           ` Chuck Wolber
2025-11-26 13:55             ` Greg KH

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='CA+wEVJZEho_9kvaGYstc=5f6iHGi69x=_0zT+jrC2EqSFUQMWQ@mail.gmail.com' \
    --to=gpaoloni@redhat.com \
    --cc=acarmina@redhat.com \
    --cc=chuckwolber@gmail.com \
    --cc=corbet@lwn.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=safety-architecture@lists.elisa.tech \
    --cc=shuah@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