This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: SystemTap Kernel Runtime Library
- From: Martin Hunt <hunt at redhat dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Mon, 07 Feb 2005 13:48:23 -0800
- Subject: Re: SystemTap Kernel Runtime Library
- Organization: Red Hat Inc.
- References: <1107463629.5532.1.camel@tiger> <20050207212418.GA22533@redhat.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