[LTP] [RFC] Define minimal supported kernel and (g)libc version

[LTP] [RFC] Define minimal supported kernel and (g)libc version

[Petr Vorel]

Hi,

I'm sorry, I've raised this question in the past, but it got lost.
I remember we talked about 2.6 something.

It'd be good to state publicly the oldest kernel and glibc (or even other libc
versions) we support.  This would allow us to remove some legacy code or force
support for legacy code.

This shouldn't require test to be functional (e.g. for some cases like module
drivers it could be hard), but LTP to be compiled and when difficult/impossible
to achieve this functionality, it could resulted in TCONF (skipped test).

I created github issue for this [1], where I put link to this thread, so we
don't loose it again.

Kind regards,
Petr

[1] https://github.com/linux-test-project/ltp/issues/657

[LTP] [RFC] Define minimal supported kernel and (g)libc version

[Li Wang]

Hi Petr,

This is a good topic, thanks for kicking off this initiative!

On Fri, Mar 13, 2020 at 10:15 PM Petr Vorel <pvorel@suse.cz> wrote:

> Hi,
>
> I'm sorry, I've raised this question in the past, but it got lost.
> I remember we talked about 2.6 something.
>

Yes, the past discussion is still valuable to us. see:
http://lists.linux.it/pipermail/ltp/2019-May/011990.html


> It'd be good to state publicly the oldest kernel and glibc (or even other
> libc
> versions) we support.  This would allow us to remove some legacy code or
> force
> support for legacy code.
>

Maybe we could also state the oldest GCC version too? Though I haven't seen
any conflict or supporting issue from my side, it helps avoid some
potential error in cross-compilation I guess.

    i.e.  kernel-3.10.0 / glibc-2.17 / gcc-4.8.0


>
> This shouldn't require test to be functional (e.g. for some cases like
> module
> drivers it could be hard), but LTP to be compiled and when
> difficult/impossible
> to achieve this functionality, it could resulted in TCONF (skipped test).
>
+1


>
> I created github issue for this [1], where I put link to this thread, so we
> don't loose it again.
>
> Kind regards,
> Petr
>
> [1] https://github.com/linux-test-project/ltp/issues/657
>
>

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20200314/6475dc29/attachment.htm>

[LTP] [RFC] Define minimal supported kernel and (g)libc version

[Petr Vorel]

Hi Li,

> This is a good topic, thanks for kicking off this initiative!
Thanks for your input.

> > I'm sorry, I've raised this question in the past, but it got lost.
> > I remember we talked about 2.6 something.

> Yes, the past discussion is still valuable to us. see:
> http://lists.linux.it/pipermail/ltp/2019-May/011990.html
Great, thanks!

> > It'd be good to state publicly the oldest kernel and glibc (or even other
> > libc
> > versions) we support.  This would allow us to remove some legacy code or
> > force
> > support for legacy code.


> Maybe we could also state the oldest GCC version too? Though I haven't seen
> any conflict or supporting issue from my side, it helps avoid some
> potential error in cross-compilation I guess.
+1
Not sure if we want to specify also clang.

>     i.e.  kernel-3.10.0 / glibc-2.17 / gcc-4.8.0
This is for RHEL7 I guess.

The oldest system in travis we have CentOS 6: kernel-2.6.32 / glibc-2.12 /
gcc-4.4.7 (clang-3.4.2, but we don't test it with clang). I'm ok to have this
older dependency, just to make sure it builds.  But code would be cleaner for
sure if we drop it.

BTW I also occasionally test build on SLES 11-SP3 (kernel 3.0 / glibc-2.11.3 /
gcc-4.3.4 - older glibc and gcc), but this is not even in travis.
But for testing these distros we use older releases (the same mentioned Jan [1]).
I wonder if there is really somebody using 2.6.x or 3.x < 3.10 on master.
If not, we can drop some lapi files which mention 2.6.

Kind regards,
Petr

[1] http://lists.linux.it/pipermail/ltp/2019-May/011991.html

[LTP] [RFC] Define minimal supported kernel and (g)libc version

[Li Wang]

Hi Petr,

On Tue, Mar 17, 2020 at 4:15 PM Petr Vorel <pvorel@suse.cz> wrote:

> Hi Li,
>
> > This is a good topic, thanks for kicking off this initiative!
> Thanks for your input.
>
> > > I'm sorry, I've raised this question in the past, but it got lost.
> > > I remember we talked about 2.6 something.
>
> > Yes, the past discussion is still valuable to us. see:
> > http://lists.linux.it/pipermail/ltp/2019-May/011990.html
> Great, thanks!
>
> > > It'd be good to state publicly the oldest kernel and glibc (or even
> other
> > > libc
> > > versions) we support.  This would allow us to remove some legacy code
> or
> > > force
> > > support for legacy code.
>
>
> > Maybe we could also state the oldest GCC version too? Though I haven't
> seen
> > any conflict or supporting issue from my side, it helps avoid some
> > potential error in cross-compilation I guess.
> +1
> Not sure if we want to specify also clang.
>

I do not use clang often, so I hope others can advise more here.


>
> >     i.e.  kernel-3.10.0 / glibc-2.17 / gcc-4.8.0
> This is for RHEL7 I guess.
>
Correct.


>
> The oldest system in travis we have CentOS 6: kernel-2.6.32 / glibc-2.12 /
> gcc-4.4.7 (clang-3.4.2, but we don't test it with clang). I'm ok to have
> this
> older dependency, just to make sure it builds.  But code would be cleaner
> for
> sure if we drop it.
>
+1
Sounds good to me.

>
> BTW I also occasionally test build on SLES 11-SP3 (kernel 3.0 /
> glibc-2.11.3 /
> gcc-4.3.4 - older glibc and gcc), but this is not even in travis.
> But for testing these distros we use older releases (the same mentioned
> Jan [1]).
>

Agreed, we can explicitly declare that(in some place of Doc) from a
specific LTP(e.g ltp-full-20200120) version, we don't provide code
supporting for the older kernel/glibc/gcc package anymore. If people who
are going to test old distros, they can just pick up an old released LTP
version and hack it by themself. The latest branch of LTP doesn't accept
that patch for old things.

> I wonder if there is really somebody using 2.6.x or 3.x < 3.10 on master.
> If not, we can drop some lapi files which mention 2.6.
>
> Kind regards,
> Petr
>
> [1] http://lists.linux.it/pipermail/ltp/2019-May/011991.html
>
>

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20200317/568e8c22/attachment.htm>

[LTP] [RFC] Define minimal supported kernel and (g)libc version

[Petr Vorel]

Hi Li,

> > The oldest system in travis we have CentOS 6: kernel-2.6.32 / glibc-2.12 /
> > gcc-4.4.7 (clang-3.4.2, but we don't test it with clang). I'm ok to have
> > this
> > older dependency, just to make sure it builds.  But code would be cleaner
> > for
> > sure if we drop it.

> +1
> Sounds good to me.
I'm sorry, are you for removing CentOS 6 from Travis or not?


> > BTW I also occasionally test build on SLES 11-SP3 (kernel 3.0 /
> > glibc-2.11.3 /
> > gcc-4.3.4 - older glibc and gcc), but this is not even in travis.
> > But for testing these distros we use older releases (the same mentioned
> > Jan [1]).


> Agreed, we can explicitly declare that(in some place of Doc) from a
> specific LTP(e.g ltp-full-20200120) version, we don't provide code
> supporting for the older kernel/glibc/gcc package anymore. If people who
> are going to test old distros, they can just pick up an old released LTP
> version and hack it by themself. The latest branch of LTP doesn't accept
> that patch for old things.
+1

Kind regards,
Petr

[LTP] [RFC] Define minimal supported kernel and (g)libc version

[Li Wang]

Hi Petr,

On Tue, Mar 17, 2020 at 5:04 PM Petr Vorel <pvorel@suse.cz> wrote:

> Hi Li,
>
> > > The oldest system in travis we have CentOS 6: kernel-2.6.32 /
> glibc-2.12 /
> > > gcc-4.4.7 (clang-3.4.2, but we don't test it with clang). I'm ok to
> have
> > > this
> > > older dependency, just to make sure it builds.  But code would be
> cleaner
> > > for
> > > sure if we drop it.
>
> > +1
> > Sounds good to me.
> I'm sorry, are you for removing CentOS 6 from Travis or not?
>

I previously think these words mean that only make sure LTP build passes on
CentOS6(but not remove it).

But removing is also Ok to me, we can do that after we reaching an
agreement on the supporting package-version and write it down in Docs. That
probably occurring in the next release if everything goes well:).

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20200317/ecf3daff/attachment.htm>

[LTP] [RFC] Define minimal supported kernel and (g)libc version

[Jan Stancek]

----- Original Message -----
> Hi Li,
> 
> > This is a good topic, thanks for kicking off this initiative!
> Thanks for your input.
> 
> > > I'm sorry, I've raised this question in the past, but it got lost.
> > > I remember we talked about 2.6 something.
> 
> > Yes, the past discussion is still valuable to us. see:
> > http://lists.linux.it/pipermail/ltp/2019-May/011990.html
> Great, thanks!
> 
> > > It'd be good to state publicly the oldest kernel and glibc (or even other
> > > libc
> > > versions) we support.  This would allow us to remove some legacy code or
> > > force
> > > support for legacy code.
> 
> 
> > Maybe we could also state the oldest GCC version too? Though I haven't seen
> > any conflict or supporting issue from my side, it helps avoid some
> > potential error in cross-compilation I guess.
> +1
> Not sure if we want to specify also clang.
> 
> >     i.e.  kernel-3.10.0 / glibc-2.17 / gcc-4.8.0
> This is for RHEL7 I guess.

Correct, it's still active (though in less extent than RHEL8). But
I still see value of running/supporting LTP here.

As I said in previous thread, if we want to draw a line somewhere,
e.g. say anything older 10 years is too old, RHEL6/Centos6 would
fall in that. For regression tests it should be OK to use older
stable release.

> 
> The oldest system in travis we have CentOS 6: kernel-2.6.32 / glibc-2.12 /
> gcc-4.4.7 (clang-3.4.2, but we don't test it with clang). I'm ok to have this
> older dependency, just to make sure it builds.  But code would be cleaner for
> sure if we drop it.
> 
> BTW I also occasionally test build on SLES 11-SP3 (kernel 3.0 / glibc-2.11.3
> /
> gcc-4.3.4 - older glibc and gcc), but this is not even in travis.
> But for testing these distros we use older releases (the same mentioned Jan
> [1]).
> I wonder if there is really somebody using 2.6.x or 3.x < 3.10 on master.
> If not, we can drop some lapi files which mention 2.6.

There are some, since LTP didn't reject such patches yet. But updates to
those old kernels are few and far between, so it might be not be worth
the trouble from LTP point of view.

[LTP] [RFC] Define minimal supported kernel and (g)libc version

[Petr Vorel]

Hi,

> Correct, it's still active (though in less extent than RHEL8). But
> I still see value of running/supporting LTP here.

> As I said in previous thread, if we want to draw a line somewhere,
> e.g. say anything older 10 years is too old, RHEL6/Centos6 would
> fall in that. For regression tests it should be OK to use older
> stable release.

OK. We can remove CentOS 6 (or probably replace with CentOS 7) now or after next
release. I don't have a strong opinion about it.
After it's removal all that 2.6.x fixes in m4/ should be deleted.

I'd be for putting supported versions in README.md.

> > The oldest system in travis we have CentOS 6: kernel-2.6.32 / glibc-2.12 /
> > gcc-4.4.7 (clang-3.4.2, but we don't test it with clang). I'm ok to have this
> > older dependency, just to make sure it builds.  But code would be cleaner for
> > sure if we drop it.

> > BTW I also occasionally test build on SLES 11-SP3 (kernel 3.0 / glibc-2.11.3
> > /
> > gcc-4.3.4 - older glibc and gcc), but this is not even in travis.
> > But for testing these distros we use older releases (the same mentioned Jan
> > [1]).
> > I wonder if there is really somebody using 2.6.x or 3.x < 3.10 on master.
> > If not, we can drop some lapi files which mention 2.6.

> There are some, since LTP didn't reject such patches yet. But updates to
> those old kernels are few and far between, so it might be not be worth
> the trouble from LTP point of view.

No strong opinion. I wouldn't be against asking these people directly
(which would lead to postpone deleting legacy support after next release).

Kind regards,
Petr