From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13951 invoked by alias); 11 Dec 2006 19:29:49 -0000 Received: (qmail 13937 invoked by uid 22791); 11 Dec 2006 19:29:47 -0000 X-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 11 Dec 2006 19:29:42 +0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by mga09.intel.com with ESMTP; 11 Dec 2006 11:29:40 -0800 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by fmsmga002.fm.intel.com with ESMTP; 11 Dec 2006 11:29:40 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,521,1157353200"; d="scan'208"; a="25676903:sNHT20193741" Received: from scsmsx412.amr.corp.intel.com ([10.3.90.31]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 11:29:39 -0800 Received: from scsmsx413.amr.corp.intel.com ([10.3.90.32]) by scsmsx412.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 11:29:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Order "begin" probes are run Date: Mon, 11 Dec 2006 19:38:00 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Order "begin" probes are run Thread-Index: AccdQBnPG8IU8M0dQp66uYJBVmIzsgAFOHQA From: "Stone, Joshua I" To: "Frank Ch. Eigler" Cc: X-OriginalArrivalTime: 11 Dec 2006 19:29:38.0731 (UTC) FILETIME=[B2CBC7B0:01C71D5A] X-IsSubscribed: yes 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 X-SW-Source: 2006-q4/txt/msg00653.txt.bz2 On Monday, December 11, 2006 8:19 AM, Frank Ch. Eigler wrote: > For some time now, we have had code to set some script globals at > module-load using module options. This initialization step should > probably be defined to take place at priority 0, but uses a different > mechanism. Thus, the probe-based and module-parameter-based > initializations could have ordering problems. Ok. I checked in code on Friday to move to C-style initialization, and I think my changes made this ordering problem better as well, or at least more predictable. The module startup now goes something like this: 1. Initial load -- globals are initalized. 2. Module parameters set -- may override global values from #1. 3. Module initialization -- runs ordered begin probes, which may do anything. > I would prefer the parser to accept -2**63+1 ... 2**63-1 for literals > everywhere. This would be fine if our numbers were always signed, but we have a bit of schizophrenia in that regard. Take kernel.statement for example -- we really want an unsigned literal, as 2**63-1 is too low for kernel addresses on 64-bit platforms. We could special case it for hex values: allow the full range of uint64_t for hex literals, and otherwise limit it as you suggest. Would this be ok? And if so, do we allow '-0x...' too? Josh