This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
RE: Order "begin" probes are run
- From: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: <systemtap at sources dot redhat dot com>
- Date: Mon, 11 Dec 2006 11:29:37 -0800
- Subject: RE: Order "begin" probes are run
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