From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [RFC] Define minimal supported kernel and (g)libc version
Date: Thu, 19 Mar 2020 08:48:58 -0400 (EDT) [thread overview]
Message-ID: <2016207059.2611128.1584622138390.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20200317081547.GA15989@dell5510>
----- 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.
next prev parent reply other threads:[~2020-03-19 12:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-13 14:14 [LTP] [RFC] Define minimal supported kernel and (g)libc version Petr Vorel
2020-03-14 8:01 ` Li Wang
2020-03-17 8:15 ` Petr Vorel
2020-03-17 8:53 ` Li Wang
2020-03-17 9:04 ` Petr Vorel
2020-03-17 9:27 ` Li Wang
2020-03-19 12:48 ` Jan Stancek [this message]
2020-03-21 6:46 ` Petr Vorel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2016207059.2611128.1584622138390.JavaMail.zimbra@redhat.com \
--to=jstancek@redhat.com \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox