All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Thomas Monjalon <thomas@monjalon.net>, <dev@dpdk.org>,
	Aaron Conole <aconole@redhat.com>,
	Anatoly Burakov <anatoly.burakov@intel.com>
Subject: Re: [RFC] devtools: rewrite doc vs code check in Python
Date: Thu, 24 Sep 2026 08:33:14 +0100	[thread overview]
Message-ID: <arTSOhHVEOKr7U06@bricha3-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <20260923135430.7e16c673@phoenix.local>

On Wed, Sep 23, 2026 at 01:54:30PM -0700, Stephen Hemminger wrote:
> On Wed, 23 Sep 2026 21:19:45 +0200
> Thomas Monjalon <thomas@monjalon.net> wrote:
> 
> > 23/09/2026 20:42, Stephen Hemminger:
> > > The existing check-doc-vs-code.sh only compares rte_flow items and
> > > actions, and only for drivers whose directory matches the ini name,
> > > so none of the drivers under net/intel are checked.
> > > 
> > > Replace it and parse-flow-support.sh with a Python script covering
> > > the whole NIC feature matrix:  
> > [...]
> > >  devtools/check-doc-vs-code.py          | 1132 ++++++++++++++++++++++++
> > >  devtools/check-doc-vs-code.sh          |   84 --
> > >  devtools/parse-flow-support.sh         |   92 --
> > >  doc/guides/contributing/new_driver.rst |    4 +-
> > >  doc/guides/contributing/patches.rst    |   27 +
> > >  doc/guides/nics/features.rst           |    5 +
> > >  8 files changed, 1169 insertions(+), 180 deletions(-)
> > >  create mode 100755 devtools/check-doc-vs-code.py
> > >  delete mode 100755 devtools/check-doc-vs-code.sh
> > >  delete mode 100755 devtools/parse-flow-support.sh  
> > 
> > Thanks for working on it.
> > 
> > My concern is how easy it is to maintain for all contributors
> > having to insert their rules and exceptions?
> > 
> > It is replacing less 200 lines with more than 1000 lines
> > so it looks a lot more complex.
> > It is probably fully generated by AI?
> > Can we make it simpler?
> > 
> > 
> 
> The other suggestion would be to git rid of the .ini file method
> of generating this feature matrix in doc and just have python script
> generate it.  Prefer a single source of truth, less work

+1, I was just going to suggest that when I saw the discussion on this
script.
In case of autogeneration, for cases like "partial" support, we can have a
well-defined comment tag or similar in the code to mark it.

/Bruce

  reply	other threads:[~2026-09-24  7:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-23 18:42 [RFC] devtools: rewrite doc vs code check in Python Stephen Hemminger
2026-09-23 18:44 ` Stephen Hemminger
2026-09-23 19:19 ` Thomas Monjalon
2026-09-23 20:11   ` Stephen Hemminger
2026-09-23 20:54   ` Stephen Hemminger
2026-09-24  7:33     ` Bruce Richardson [this message]
2026-09-24  8:36       ` Thomas Monjalon
2026-09-24 15:31         ` Stephen Hemminger

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=arTSOhHVEOKr7U06@bricha3-mobl1.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=aconole@redhat.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    /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.