[LTP] LTP old API conversion

[Andrea Cervesato]

Hi all,

so we still have ~200 patches to refactor and to move from old LTP API into
the new LTP API. That would be really useful for tests maintenance and long
term supports, such as the `runtest` removal and replacement with a smarter
tests filtering/grouping.

This is a tedious task that requires a huge amount of work and in the past
years we managed to convert hundreds of tests by hand, each one requiring
multiple reviews iterations.

It was overwhelming not only for developers, but also for reviewers who
were stucked by reviewing new patches + tests rewriting.

In 2026 we have the chance to accelerate this transition from old API to
new API using LLMs and, as we discussed in the yesterday LTP after release
meeting, we might be in the right way to start doing it (at least for
smaller tests).

I created a set of configurations and skills in my personal repo which can
be used to start this process: https://github.com/acerv/agents-config.
It's maily tested using Claude Code, since it's the model which perform
the best (at the moment), but any other model can be used.

I experimented with a list of tests that can be obtained with the following
command:

wc -l $(grep -R '"test\.h"' --include="*.c" testcases/kernel/ | cut -d: -f1) | sort -g

.. and tests conversion for tests which are smaller than 200 lines of code
requires minimal (if no) edit. I will continue to adapt the ltp-convert skill
in order to tweak and to improve this process for bigger tests.

~~ Said so..

.. since this process seems to be quite straight forward, and with the usage
of LLM we could easily generate hundreds of patches per month, we don't really
want to flood the ML with garbage and to overwhelm who's involved into
maintenance review.

How we should organize this job?
Should we set a maximum amount of tests refactoring per month?
How do we organize these patches? (i.e. with blocks of patches)

Kind regards,
--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com