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 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.