Re: SystemTap Kernel Runtime Library

[Martin Hunt <hunt at redhat dot com>]

On Mon, 2005-02-07 at 16:24 -0500, Frank Ch. Eigler wrote:

> 
> Heh, you found my #define-based templating a bit too distasteful, eh?

At first I thought it was cool, but there were too many optimizations I
wanted to make.  And the error messages from the compiler got confusing.

> > The values stored in the arrays can be the following:
> > 64-bit int [...]
> 
> what is the sense of the wider audience about whether we should pick
> the native "long" (32 or 64 bits) or a fixed 64-bit data type, for
> all numeric values?  (Like dtrace, I'd like to pick just one.)
> 

My preference is to do 64-bit so we don't have to worry about values
wrapping or portability.

> > There will be functions to lookup a value, change a value, clear an
> > array, print an array, and walk an array. 
> 
> We'd also want a "delete array entry" operation.

I think clearing = deleting.  

I'm considering an implementation that would support an argument so it
can truncate (remove all but the most recent 'n' entries). Or maybe just
define a maximum number of entries in an array and old entries get
tossed automatically.
 
> We would not want one runaway systemtap
> probe function to be able to use up all the emergency atomic memory.
> I believe a non-atomic heap allocation done at module_init time, or
> even a static one done within the emitted C function, even if covering
> several megabytes, would be okay.

Yes that would work, at the cost of having a fixed limit on memory
available, and the need to write our own dynamic allocation code to
track the memory used within the giant heap allocation.

Martin