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@kernel.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 0/2] kernel-doc: better handle data prototypes
Date: Tue, 24 Mar 2026 16:33:50 +0100 [thread overview]
Message-ID: <20260324163350.2b75fe3a@localhost> (raw)
In-Reply-To: <cover.1773998596.git.mchehab+huawei@kernel.org>
On Fri, 20 Mar 2026 10:46:39 +0100
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> 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.
Heh, getting it working is hard, but I ended with something that
should work with a somewhat complex scenario.
The new version is at my scratch repository at:
https://github.com/mchehab/linux PR_CDataParser-v2
I'm expecting that this parser should be able to handle:
- typedef (for data types);
- struct
- union
- enum
- var
So, after properly integrated(*), it should simplify a lot the
code inside kdoc_parser.
(*) right now, it is minimally integrated, handling just
struct/unions.
My current plan is to test it more with real-case scenarios,
aiming to submit it after 7.1-rc1, as it sounds to be that a
change like that is too late to be submitted like that.
IMO the newer code should be more reliable than the current
approach and should produce a better output once done.
--
Thanks,
Mauro
For this input:
<snip>
/**
* struct property_entry - property entry
*
* @name: name description
* @length: length description
* @is_inline: is_inline description
* @bar: bar description
* @my_enum: my_enum description
* @test: test description
* @anonymous: anon description
* @type: type description
* @literal: literal description
* @pointer: pointer description
* @value: value description
* @boou8_data: boou8_data description
* @u16_data: u16_data description
* @u32_data: u32_data description
* @u64_data: u64_data description
* @str: str description
* @prop_name: prop name description
*/
struct property_entry {
const char *name;
size_t length;
bool is_inline; /* TEST */
struct foo {
char *bar[12];
struct {
enum enum_type my_enum; /* TEST 2 */
struct {
uint_t test; /* TEST 3 */
static const int anonymous;
};
} foobar ;
;;
{};
};
enum dev_prop_type type;
enum {
EXPRESSION_LITERAL,
EXPRESSION_BINARY,
EXPRESSION_UNARY,
EXPRESSION_FUNCTION,
EXPRESSION_ARRAY
} literal;
union {
const void *pointer;
union {
u8 boou8_data[sizeof(u64) / sizeof(u8)];
u16 u16_data[sizeof(u64) / sizeof(u16)];
u32 u32_data[sizeof(u64) / sizeof(u32)];
u64 u64_data[sizeof(u64) / sizeof(u64)];
const char *str[sizeof(u64) / sizeof(char *)];
};
};
char *prop_name;
};
</snip>
Kernel-doc produces a proper result:
<snip>
Ignoring foobar
.. c:struct:: property_entry
property entry
.. container:: kernelindent
**Definition**::
struct property_entry {
const char *name;
size_t length;
bool is_inline;
struct foo {
char *bar[12];
struct {
enum enum_type my_enum;
struct {
uint_t test;
static const int anonymous;
};
} foobar;
{
};
};
enum dev_prop_type type;
enum {
EXPRESSION_LITERAL,
EXPRESSION_BINARY,
EXPRESSION_UNARY,
EXPRESSION_FUNCTION,
EXPRESSION_ARRAY } literal;
union {
const void *pointer;
union {
u8 boou8_data[sizeof(u64) / sizeof(u8)];
u16 u16_data[sizeof(u64) / sizeof(u16)];
u32 u32_data[sizeof(u64) / sizeof(u32)];
u64 u64_data[sizeof(u64) / sizeof(u64)];
const char *str[sizeof(u64) / sizeof(char *)];
};
};
char *prop_name;
}
};
**Members**
``{unnamed_struct}``
anonymous
``name``
name description
``length``
length description
``is_inline``
is_inline description
``bar``
bar description
``my_enum``
my_enum description
``{unnamed_struct}``
anonymous
``test``
test description
``anonymous``
anon description
``type``
type description
``literal``
literal description
``{unnamed_union}``
anonymous
``pointer``
pointer description
``boou8_data``
boou8_data description
``u16_data``
u16_data description
``u32_data``
u32_data description
``u64_data``
u64_data description
``str``
str description
``prop_name``
prop name description
</snip>
prev parent reply other threads:[~2026-03-24 15:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 9:46 [PATCH RFC 0/2] kernel-doc: better handle data prototypes Mauro Carvalho Chehab
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 ` Mauro Carvalho Chehab [this message]
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=20260324163350.2b75fe3a@localhost \
--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