On Mon, 23 Feb 2026 08:02:11 -0700 Jonathan Corbet <[email protected]> wrote:
> Jani Nikula <[email protected]> writes: > > > There's always the question, if you're putting a lot of effort into > > making kernel-doc closer to an actual C parser, why not put all that > > effort into using and adapting to, you know, an actual C parser? > > Not speaking to the current effort but ... in the past, when I have > contemplated this (using, say, tree-sitter), the real problem is that > those parsers simply strip out the comments. Kerneldoc without comments > ... doesn't work very well. If there were a parser without those > problems, and which could be made to do the right thing with all of our > weird macro usage, it would certainly be worth considering. Parser is only needed for statement prototypes. There, stripping comments (after we parse public/private) should be OK. Yet, we want a python library to do the parsing, using it only for the things we want to be parsed. Assuming we have something like that, we'll still need to teach the parser about the macro transforms, as those are very Linux specific. Maybe something like: https://github.com/eliben/pycparser would help (didn't test nor tried to check if it does what we want). There is an additional problem that this will add an extra dependency for the Kernel build itself, because kernel-doc can run at Kernel build time. -- Thanks, Mauro
