From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8412 invoked by alias); 11 Jun 2014 22:48:56 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 8402 invoked by uid 89); 11 Jun 2014 22:48:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 11 Jun 2014 22:48:54 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5BMmrn9005298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 11 Jun 2014 18:48:53 -0400 Received: from [10.3.113.151] (ovpn-113-151.phx2.redhat.com [10.3.113.151]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5BMmrWl003842 for ; Wed, 11 Jun 2014 18:48:53 -0400 Message-ID: <5398DCD4.1010102@redhat.com> Date: Wed, 11 Jun 2014 22:48:00 -0000 From: Josh Stone User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: systemtap@sourceware.org Subject: RFC: raise the OS baseline for systemtap.git Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-q2/txt/msg00225.txt.bz2 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