Re: Questions and comments about the Architecture paper

[fche at redhat dot com (Frank Ch. Eigler)]

wcohen wrote:

> I read through the current version of the Architecture of systemtap
> paper.  [...]

Thanks!


> [...]
> In section "2.3 Translation" "Each group of local variables is placed
> into a synthetic call frame structure" Where is this located and/or
> created? Allocation of kernel memory when the module is loaded. 

The translator would emit static declarations of arrays containing
these synthetic frames.  Each such array consists of a fixed number of
nested frame structs, coincidentally imposing a function-call
nesting limit.

> Is this going to allow thread local storage/reentrant code? What
> happens when two different processors execute the same probe at the
> same time?

Yes, it may even be sufficient to have one synthetic frame array per
CPU, unless we try to handle reentrant probes.


> In section "2.4 Execution" the main issue with things like
> copy_from_user is context switches and locks cannot be held when there
> is a possibility of a context switch.

Right.


> In section "2.4 Execution" interrupts can't be sent to a driver in the
> same manner as a user process can get a signal. rmmod is the way to
> get rid of module.

rmmod is a user-level program.  The issue is how a kernel-resident
probe, running possibly within interrupt context, can arrange for a
timely shutdown.  rmmod is way down the pipeline in the event chain.


> At the beginning of section "3 Programming" there is an allowance of
> foward references. What happens in the case of a global variable
> declared later? [...]

Forward references and globals mix naturally: globalness may be
forward declared.  Recall that this will be needed anyway for
declaring the properties of statistics objects.


> Third paragraph of page 4.
> So there is just one name space for global variable across all
> modules? The possible name collision between instrumentation would be
> a problem.

I imagine tapset authors sticking to a convention that their internal
globals are sufficiently prefixed with "uglifiers" to stay out of the
way.


> "3.2" Language element "$" is a legal character is identifiers. Is it
> allowed anywhere in the identifier or just at the leading character?

There will be some magic associated with leading-$ names, relating to
lookup in target-space, which will need a lot more text to explain,
once it's worked out.  Stand by.


> For the types that are less than 64 bits in size are they zero
> extended for unsigned and sign extended for signed?

Sure, whatever makes sense.


> "3.3 Statements" bottom of page 6 does the iterator lock the
> associative array when it iterates through all the elements? 

We need something, but I'm not sure what.  Having a real lock could
cause deadlocks between two probe handlers that are iterating &
operating upon two arrays with opposite nesting.  We have static
analysis capabilities, and could detect obnoxious operations upon an
array being iterated.

> Similarly for Expressions are things like "++", "--", "+=", and "-="
> atomic?

For simplicity, I'll probably implement them as not-atomic at first,
but yes, ideally they should be.


> On Page 8 why the exponentiation operation? Is there some place that
> would be useful?

Probably not.  It's just something in awk.


> Would sizeof still be useful in some cases? For example computing the
> number of elements of a particular type a block of memory can hold.

maybe, but what would sizeof() be applied to, and used for?  Remember,
we don't have type naming expressions.


> I like the probe aliases.

I'm glad.  What I like about it most is how it doesn't seem too
contrived or complicated.


> Section "4.2 C tapsets" is this lower level stuff for writing tapsets in C?
> [...]

Yeah, for that last 10-0% of cases. :-)


- FChE