RFC: raise the OS baseline for systemtap.git

RFC: raise the OS baseline for systemtap.git

[Josh Stone]

SystemTap arose in the RHEL4 era, and we've done our best to maintain
that compatibility ever since.  I'd like to know what people think about
raising that baseline, and I suggest starting from RHEL6.  That's a
2.6.32-ish kernel and gcc 4.4.

This would have no effect on RHEL's own systemtap packages, just our
policy for systemtap.git and future releases.  Both RHEL4 and RHEL5 are
past Production 1 phase anyway.

Of course, it's not only about RHEL.  Fedora is way past RHEL6, no
problem.  Debian's eldest (squeeze) also has 2.6.32 and gcc 4.4, as does
Ubuntu 10.4 LTS (lucid).  SLES11 SP1 has 2.6.32, but only gcc 4.3, while
openSUSE 11.4 is on 2.6.37 with gcc 4.5.  I suspect most others distros
that might care are newer anyway, but please speak up.


To what end?

For starters, just raising the bar to 2.6.32 relaxes our development
effort a bit, so we don't need to be quite so careful about available
kernel APIs.  That's helpful for new development, and would also let us
clean up a lot of old stapconf #ifdef code.

A few other features are obsolete in 2.6.32+, and could be removed:
- kernel markers, dead since fc5377668c3d (v2.6.32-rc1~615^2~4).
- timer.s probes' old timer interface, in favor of hrtimers.
- timer.profile's register_profile_notifier.
- runtime/linux/uprobes for RHEL5's utrace. (uprobes2/ is for RHEL6)
- runtime/transport version 1 (relayfs).

There's probably a lot of @defined-conditional tapset code that could
also be simplified, but that may be hard to audit.

Removing old code is not just for fun (though I do enjoy it), but it
would also reduce complexity, aid readability, etc. etc.

I mentioned GCC versions because 4.4 also has a bit of C++11.  Using
'auto' in particular would be a nice start.  We won't be able to use
that if we maintain SLES11 SP1 support with its GCC 4.3, but I see its
SDK has gcc 4.5, so I hope that's fine.


So basically, here's a chance to remove old code and start using C++11.
Feedback is welcome.  Silence may be taken as assent.  :)

Thanks,
Josh

Re: RFC: raise the OS baseline for systemtap.git

[Josh Stone]

On 06/11/2014 03:48 PM, Josh Stone wrote:
> Of course, it's not only about RHEL.  Fedora is way past RHEL6, no
> problem.  Debian's eldest (squeeze) also has 2.6.32 and gcc 4.4, as does
> Ubuntu 10.4 LTS (lucid).  SLES11 SP1 has 2.6.32, but only gcc 4.3, while
> openSUSE 11.4 is on 2.6.37 with gcc 4.5.  I suspect most others distros
> that might care are newer anyway, but please speak up.

Lukas pointed out that we should also be mindful of CentOS, SL, et al.
I think for this purpose they can be treated as properly equivalent to
RHEL, so we'd support CentOS6/SL6 and up, but let me know if you think
there's more nuance to it than that.

Re: RFC: raise the OS baseline for systemtap.git

[Josh Stone]

(I'm not talking to myself, just relaying irc conversations...)

Frank is feeling more conservative about this, that we shouldn't
deliberately remove code that some people might still want.  He conceded
that we might just declare pre-RHEL6-ish platforms to be deprecated, no
longer actively tested, but still accepting bug reports and patches.
This would at least relieve some development burden for now.  Jonathan
added that we might set a timeline after which we can actively start
removing that old code.

I think it's likely that those deprecated platforms will bitrot and
break pretty quickly, if we're not testing them and developing with them
in mind.  But perhaps that makes it a good litmus test whether anyone
cares.  So I'd say we should deprecate them for a set period, say the
next two releases, and if we don't see pushback then we can start
actively pruning and allow things like C++11.