This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: tapset feedback
hunt wrote:
> 1. My biggest issue with the way tapsets are implemented is that there
> are no namespaces or ways to limit the scope of a function. Plus the
> concepts of code libraries and tapsets are overlapped. [...]
The HACKING file includes simple suggestions for prefixing internal
identifiers to avoid namespace collisions.
> 2. I am not running 2.6.14, 2.6.9-20.ELsmp, or 2.6.9-24.ELsmp on any
> of my machines, so I cannot use the syscalls tapset. [...]
The syscalls tapset has undergone several drastic changes. This
latest repackaging was checked in without consultation, and indeed I
don't think it's quite right. So please don't use that as a sole
example to indict the whole scheme.
> > [...] a user script might want to use kernel.syscall.foobar
> > directly, then it will have to use % conditionals to avoid those
> > uses on kernels where the probe won't be defined because it can't
> > work; i.e., have to know the kernel versions to test for,
>
> This is exactly the ugly situation we now have.
I don't understand why you think this is "ugly". If an user script
specifically asks for a particular probe (.foobar), and it does not
exist, why should the user be surprised by an error or having to work
around it?
> For every function that gets added/removed we have to know the exact
> kernel versions it happened in.
That's a different "we" - a systemtap library script developer. Yes,
if such a developer decides to target a very fluid API, then she will
pay the price of having to conditionalize it sufficiently.
> [...] What I REALLY would like to see is a way to say "here is a
> list of probe points. Set probes on as many as possible."
Why exactly would you want to say something like that, and not by
using wildcards?
- FChE