From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3012 invoked by alias); 13 Feb 2006 19:40:59 -0000 Received: (qmail 2991 invoked by uid 22791); 13 Feb 2006 19:40:57 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 13 Feb 2006 19:40:55 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k1DJerRm001103 for ; Mon, 13 Feb 2006 14:40:53 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k1DJel129841; Mon, 13 Feb 2006 14:40:47 -0500 Received: from vpn83-128.boston.redhat.com (vpn83-128.boston.redhat.com [172.16.83.128]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id k1DJejBi003043; Mon, 13 Feb 2006 14:40:46 -0500 Subject: Re: Global constants From: Martin Hunt To: "Frank Ch. Eigler" Cc: Mark McLoughlin , systemtap@sourceware.org In-Reply-To: References: <1139852331.11054.17.camel@localhost.localdomain> Content-Type: text/plain Organization: Red Hat Inc Date: Mon, 13 Feb 2006 19:40:00 -0000 Message-Id: <1139859707.3942.11.camel@monkey2> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-25) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q1/txt/msg00490.txt.bz2 On Mon, 2006-02-13 at 14:28 -0500, Frank Ch. Eigler wrote: > The standard syscalls tapset should define such constants, so end-user > scripts do not have to. Hien and I are currently rewriting the syscall tapset, so if constants get implemented soon, we can make immediate use of them. > If read-only-ness of these globals is important, then a new "const" > keyword would indeed come in handy. (I'd promptly reuse it as a > qualifier for embedded-C functions that are declared to have no > side-effects.) I would implement this angle by a new flag on vardecl, > enforced non-lvalueness during elaboration or translation, rather than > whole new staptree.h classes. Declaring variables readonly reduces the probe complexity by removing the global locks around all variable access. So it clearly seems like a win. Also it would be nice to have a way to declare these constants in embedded C, so we can use the C header files to get the values, rather than look them up. something like %{ const_O_CREAT = O_CREAT; %} instead of O_CREAT = 64