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]

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


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