This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RFC: raise the OS baseline for systemtap.git


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]