Re: [LTP] [PATCH 0/7] docparse improvements

[Cyril Hrubis <chrubis@suse.cz>]

Hi!
> >> > Still working on a prototype based on tree-sitter would take a week or
> >> > two worth of time and I would like to get the metadata fixed now, so
> >> > that I can finally move on with runltp-ng. So I would slightly prefer
> >> > merging the patches for the current solution first, then we can have a
> >> > look on tree-sitter in the next LTP release cycle. What do you think?
> >> 
> >> I think there is a small risk
> >> 
> >> 1. It turns out that with tree-sitter it would make more sense to use a
> >>    different meta-data format.
> >
> > What do you have in mind? I do not think that we should dramatically
> > chante the json structure we do have now.
> 
> Whatever tree-sitter produces most naturally and requires the least
> amount of massaging.

I do not think that there will be a big differences though, the only
difference would be that we would get proper types, i.e. strings vs
integers. The rest of the processing we do filters out fields we are not
interested in, or checks if implied flags are not defined, etc. that is
going to stay regardless.

> >> Note that in general I think it's best (on bigger projects) to have an
> >> alternative branch for big changes where one needs to "rush" to an
> >> end-to-end solution. Most likely we need an alternate branch for
> >> integrating runltp-ng and the executor.
> >
> > We can even do this in a separate github repository or whatever works,
> > but still we have to agree on general direction.
> >
> > I still think that the best solution here is to apply this patchset and
> > put the tree-sitter on TODO. Unlike tree-sitter this is neither big nor
> > radical change and it would allow us to proceed with other stuff that
> > has been blocked for several releases at least.
> 
> As discussed in IRC, I prefer the route of trying either Sparse or
> Tree-sitter first to produce the metadata. However please go ahead and
> make the decision. After all once we have better automation it will
> reduce the burden on reviewers.

I've send a v2 for the patchset. I still think that we should merge
that in order to get usable metadata now so that we can finally
implement/fix several issues, namely:

https://github.com/linux-test-project/ltp/issues/868

Here we really need the metadata available and loaded in the testrunner
so that we know that reboot is comming. This one can be implemented only
with the last patch of the series that installs the json metadata
unconditionally.


https://github.com/linux-test-project/ltp/issues/824

This one is more complicated though, also the mmap1 is not the only test
that suffers from this condition, there is at least writev03 that
suffers from timeouts.

In order to compute the test runtime properly we need to know the upper
limit for the test iterations, which is currently multiplication of
.test_variants and supported filesystems if .all_filesystems is set,
which is the main motivation behing pushing this patchset forward along
with the runtime patchset. Once these two are merged, the test runtime
and safe enough timeout can be easily computed from the test metadata
and used by the testrunners.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp