[LTP] New LTP documentation!

[Li Wang]

On Thu, Apr 11, 2024 at 9:38 PM Petr Vorel <pvorel@suse.cz> wrote:

> Hi Li,
>
> > Hi Petr,
>
> > On Wed, Apr 10, 2024 at 6:12 PM Petr Vorel <pvorel@suse.cz> wrote:
>
> > > Hi all,
>
> > > > Hi Andrea,
>
> > > > On Mon, Mar 18, 2024 at 8:41 PM Andrea Cervesato via ltp <
> > > ltp@lists.linux.it>
> > > > wrote:
>
> > > > > Hello everyone,
>
> > > > > as already mentioned in the monthly LTP meeting, Linux Test Project
> > > > > lacks of a nice and clean documentation that can be easily
> accessed by
> > > > > users, developers and maintainers.
> > > > > The current LTP documentation is also not matching with our
> expectancy
> > > > > towards the entire project, which is has been heavily refactored
> and it
> > > > > has changed in the past years, providing a higher quality code and
> new
> > > > > testing features.
>
> > > > > For this reasons, we think it's time to move forward and to start
> > > > > working on documentation, helping people to use, to develop and to
> > > > > maintain LTP in an easier way, increasing quality of the overall
> > > project
> > > > > and to call more developers in the community.
>
> > > > > I started to work on documentation refactoring, re-organizing the
> > > > > overall structure. The first prototype can be found here:
>
> > > > > https://ltp-acerv.readthedocs.io/en/latest/index.html
>
>
> > > > Looks great! Thanks for bringing this.
>
> > > > And I just tried that the latest LTP compiled & executed succeed on
> > > > RHEL-7.9.
> > > > Can you update the "Oldest tested distributions" [1] part by adding:
>
> > > >   RHEL-7.9 Maipo (Distro)  3.10 (kernel)  4.8.5(gcc)  2.17(glibc)
> > > -(clang)
>
> > > Although in the original docs, the table was not under section "Build
> > > testing
> > > with GitHub Actions", I assumed it's clear we talk about GitHub Actions
> > > testing.
> > > That's why I put there only distros we actually have in
> > > .github/workflows/ci.yml
> > > and not e.g. SLE12-SP2 which we test with latest LTP release.
>
> > > I actually find useful to stand which distros we test privately, but
> this
> > > info
> > > should be obvious (either add a column "CI", where would be "GitHub
> > > Actions" or
> > > "RHEL private CI" or whatever.
>
>
>
>
> > > @Li Andrea put there as new info: "Minimal supported kernel version is
> > > 3.10."
> > > which is not in old docs. Do you really test RHEL-7.9 (3.10 based)
> with the
> > > latest LTP release?
>
>
> > Yes, I did but only checked on RHEL-7.9 with x86_64 and s390x
> > (compile & execution well) last time.
>
> > After rebuilding the latest branch on all arches, I found the rest
> > arches have
> > problems in compiling (forgive me careless last time).
>
> > Now I am hesitant to fix the error or raise the baseline to RHEL8.3.
> > (I talked to colleagues and got to know they always chose to use fixed
> > versions of LTP when <=RHEL8.2).
>
> Thanks for info! Even you fix the compilation outdated info is why I would
> delete RHEL 7.9 info and 3.10 based kernel from our docs. Currently I'm not
> fixing test runtime issues even for SLE12-SP3 (kernel 4.4 based). Having
> "we
> support kernel 3.10" is asking for random testing folks creating useless
> github
> issues "test broken on kernel >= 3.10 < 4.19 (oldest mainline longterm
> kernel).
>


Yes, Make sense!

Please feel free to delete that line about RHEL7.9, we shouldn't leave
holes open to risk between kernel 3.10 and 4.19 versions.

(or at least bump up the support to kernel-4.18 (rhel8), but consider the
CI only tests on fedora and Centos-stream9, so let's give up it)



>
> I would really state what we test in CI and did not give false expectation
> about
> the actual test functionality. And if we really want to state what we
> build for,
> I'd prefer mentioning that we are compile for that distro (i.e. tests
> still can
> have bugs, it might be skipped due old config and bug not notice or test
> failure
> but WONTFIX etc). Again, missed update when we change GitHub Actions setup
> is
> easily to be checked, but claiming something is testing private CI is
> asking to
> have outdated info sooner or later.
>

+1

Let's align the maintenance version (In Doc) with GitHub Actions.



>
> Kind regards,
> Petr
>
> > ---------------------
> > # 3.10.0-1136.el7.ppc64le
>
> > # glibc-2.17-316.el7.ppc64le
>
> > In file included from /usr/include/termios.h:40:0,
> >                  from /usr/include/bits/ioctl-types.h:5,
> >                  from /usr/include/sys/ioctl.h:29,
> >                  from ../../../../include/lapi/ioctl.h:11,
> >                  from ioctl02.c:31:
> > /usr/include/bits/termios.h:33:8: error: redefinition of ‘struct termios’
> >  struct termios {
> >         ^
> > In file included from ioctl02.c:29:0:
> > /usr/include/asm/termbits.h:22:8: note: originally defined here
> >  struct termios {
> >         ^
>
>
> Hm, not in https://sourceware.org/glibc/wiki/Synchronizing_Headers.
>
> I suspect:
> 697a06a82 ("ioctl02: Use correct termios structure")
>
> That was required to fix runtime error on ppc64le, not sure if it's easy
> to be
> fixed (m4 macro would be probably required).
>
> If not, feel free to bisect, whether one of these or something else broke
> it:
>
> 8878fc683 ("ioctl,pty: Add fallback definition of struct termio")
> fed63ce97 ("pty03: Add fallback definition for TIOCVHANGUP")
>


Thanks, I wouldn't send a patch to fix it, to avoid compilation
complications.
Let's look ahead :).

We suggest people pick up fixed version ltp-20210927[1] for older RHEL7
testing if people ask.

[1] This version has stood the test of time internally for the RHEL7 series.


-- 
Regards,
Li Wang