From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Linux Doc Mailing List <linux-doc@vger.kernel.org>,
Jonathan Corbet <corbet@lwn.net>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-kernel@vger.kernel.org
Subject: [PATCH RFC 0/2] kernel-doc: better handle data prototypes
Date: Fri, 20 Mar 2026 10:46:39 +0100 [thread overview]
Message-ID: <cover.1773998596.git.mchehab+huawei@kernel.org> (raw)
Hi Jon,
Don't merge this series. It is just a heads on about what I'm
working right now.
This is basically a proof of concept, not yet integrated with
kernel-doc. It helps to show that investing on a tokenizer
was a good idea.
I'm still testing the code.
Right now, kernel-doc logic to handle data types is very
complex, and the code is split into dump_<type> functions, which
in turn calls several ancillary routines. The most complex ones
are related to handling struct, with involves converting inner
struct/unions into members of the main struct.
By using this new code, all elements from most data types can
be parsed with a single code.
Please notice that the code was designed to pick a single
declaration, as this is how kdoc_parser will use it.
If you try to parse multiple ones, the output won't be right,
as it will pick the first declaration name and create a single
item with all data declarations on it.
As it is not based on regexes, it can properly handle some
problematic cases, like having:
{};
and:
;;;;;
in the middle of a struct/union.
For enums, if one has values inside the declaration, like:
enum { FOO, BAR } type;
It picks the right data type. Kernel-doc maps this currently as:
enum type
My plan is to integrate it at Kernel-doc and see how it goes.
It will likely rise some corner cases, but, once we get it right,
this will likely reduce the size and complexity of kdoc_parser.
If you want to test, you can use:
./parse_c.py
to use an example hardcoded on it, or it reads from a fname with:
$ ./parse_c.py x.h
CDataItem(decl_type=None, decl_name=None, parameterlist=['u16_data'], parametertypes={'u16_data': 'u16 u16_data[sizeof(u64) / sizeof(u16)]'})
None None
parameterlist:
- u16_data
parametertypes:
- u16_data: u16 u16_data[sizeof(u64) / sizeof(u16)]
(on this example, x.h has just:
u16 u16_data[sizeof(u64) / sizeof(u16)];
)
The logic stores decl_type and decl_name when the data is
struct/union/enum. If the data is just a declaration, it fills
only one element at parameterlist and at parametertypes.
Mauro Carvalho Chehab (2):
docs: kdoc: add a class to parse data items
HACK: add a parse_c.py file to test CDataParser
parse_c.py | 87 +++++++++++
tools/lib/python/kdoc/data_parser.py | 211 +++++++++++++++++++++++++++
2 files changed, 298 insertions(+)
create mode 100755 parse_c.py
create mode 100644 tools/lib/python/kdoc/data_parser.py
--
2.53.0
next reply other threads:[~2026-03-20 9:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 9:46 Mauro Carvalho Chehab [this message]
2026-03-20 9:46 ` [PATCH RFC 1/2] docs: kdoc: add a class to parse data items Mauro Carvalho Chehab
2026-03-20 9:46 ` [PATCH RFC 2/2] HACK: add a parse_c.py file to test CDataParser Mauro Carvalho Chehab
2026-03-24 15:33 ` [PATCH RFC 0/2] kernel-doc: better handle data prototypes Mauro Carvalho Chehab
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=cover.1773998596.git.mchehab+huawei@kernel.org \
--to=mchehab+huawei@kernel.org \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@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