Re: [PATCH v2 00/25] kernel-doc: make it parse new functions and structs

[Jacob Keller]

On 1/28/2026 9:27 AM, Jonathan Corbet wrote:
> Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> writes:
>
> > Hi Jon,
> >
> > It is impressive how a single patch became a series with 25 ones ;-)
>
> *sigh*

Splitting things up helped me understand all the changes at least :)

> I will try to have a good look at these shortly.  It seems pretty clear
> that this isn't 7.0 material at this point, though.
>
> One thing that jumped at me:
>
> > Ah, due to the complexity of NestedMatch, I opted to write
> > some unit tests to verify that the logic there is correct.
> > We can use it to add other border cases.
> >
> > Using it is as easy as running:
> >
> > 	$ tools/unittests/nested_match.py
> >
> > (I opted to create a separate directory for it, as this
> > is not really documentation)
>
> Do we really need another unit-testing setup in the kernel?  I can't say
> I'm familiar enough with kunit to say whether it would work for
> non-kernel code; have you looked and verified that it isn't suitable?

I'm not sure kunit would be suitable here, since its meant for running 
kernel code and does a lot of stuff to make that possible. It might be 
able to be extended, but.. this is python code. Why *shouldn't* we use 
one of the python unit test frameworks for it?

We have other python code in tree. Does any of that code have unit tests?

I agree that it doesn't make sense to build new bespoke unit tests 
different or unique per each python module, so if we want to adopt 
python unit tests we should try to pick something that works for the 
python tools in the kernel.

Perhaps finding a way to integrate this with kunit so that you can use 
"kunit run" and get python tests executed as well would make sense? 
But.. then again this isn't kernel code so I'm not sure it makes sense 
to conflate the tests with kernel unit tests.

> Thanks,
>
> jon