From: Omokefe Emmanuel Onanaroghene <emmaonana18@gmail.com>
To: bvanassche@acm.org
Cc: peterz@infradead.org, elver@google.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
corbet@lwn.net, skhan@linuxfoundation.org, rdunlap@infradead.org,
mchehab@kernel.org, aleksandr.loktionov@intel.com,
kees@kernel.org, tudor.ambarus@linaro.org
Subject: Re: [PATCH] docs: kdoc: parse context_lock_struct() as struct declaration
Date: Sat, 26 Sep 2026 10:54:05 +0100 [thread overview]
Message-ID: <20260926095405.56438-1-emmaonana18@gmail.com> (raw)
In-Reply-To: <5315b896-e496-4020-9e46-77ffb942ea37@acm.org>
Hi Bart,
> Has this alternative been considered: instead of modifying
> tools/lib/python/kdoc/kdoc_parser.py, apply the following change:
Thanks for taking the time to review this. I tried your split
(`context_lock_struct()` above the comment, plain `struct` below), and it
does fix the warning.
> +context_lock_struct(debugfs_cancellation);
> ...
> -context_lock_struct(debugfs_cancellation) {
> +struct debugfs_cancellation {
I still think the tool-side fix is the better route: `debugfs_cancellation`
is the only one with a kernel-doc comment today, but the next comment
added above any of the others would hit the same error, and we'd be
fixing the same warning again.
The part that really sold me on changing the tool was a general ordering
issue in `dump_struct()`: unlike `dump_var()` and `dump_function()`, it
applied the transforms only to the members after `split_struct_proto()`,
so they could never repair the declaration line itself. Moving the
transform earlier fixes that, and a full-tree A/B test removes the
existing warning without adding any new ones.
Would you and Marco prefer the tool-side fix, or should I respin with the
`debugfs.h` change?
Thanks,
Omokefe
next prev parent reply other threads:[~2026-09-26 9:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-25 23:40 Omokefe Emmanuel Onanaroghene
2026-09-26 0:14 ` Bart Van Assche
2026-09-26 4:56 ` Randy Dunlap
2026-09-26 9:54 ` Omokefe Emmanuel Onanaroghene [this message]
2026-09-26 15:16 ` Jonathan Corbet
2026-09-26 16:24 ` Omokefe Emmanuel Onanaroghene
2026-09-26 16:35 ` Jonathan Corbet
2026-09-26 18:41 ` Randy Dunlap
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=20260926095405.56438-1-emmaonana18@gmail.com \
--to=emmaonana18@gmail.com \
--cc=aleksandr.loktionov@intel.com \
--cc=bvanassche@acm.org \
--cc=corbet@lwn.net \
--cc=elver@google.com \
--cc=kees@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=skhan@linuxfoundation.org \
--cc=tudor.ambarus@linaro.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
all inboxes | Powered by JetHome®