Re: Script tapsets.

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

brad.chen wrote:

> [...]
> I see three sets of people involved:
> - Systemtap developers: us
> - Tapset developers: kernel experts
> - Systemtap users: performance experts but not kernel experts
>
> Frank's interests here sometimes confuse me because he seems to blur
> the distinction [...]

Absolutely, the distinctions are not so distinct.  

For example, a sufficiently detailed tapset description file (see the
template(tm)), bridges gap between the "kernel experts" and "systemtap
developers", allowing the latter to write the probes, to poke at the
data identified by the former.

For another example I bring up frequently, "tapset developers" can be
plain "tapset users" that are just slightly more knowledgeable than
the people wishing to reuse their scripts.

For another example, the kernel experts who hypothetically want to
only write tapset libraries in C would have little motivation to do so
(and little hope of writing correct code), unless they actually *use*
the script side of the system.  So even this group of people would be
included in "systemtap users".  I get the impression that many of
Sun's own kernel people turned into dtrace users.


> [...]  why though should we prevent tapset developers from working
> where they feel most comfortable?  [...]

It's just a matter of separating policy and mechanism.  :-) :-) No,
seriously, if someone proposed a clean design for this, that would be
great.  Jim Keniston's embedded-C story was a good example, since it
addressed many of the required technical issues.  If nothing better
comes along, something like that could be adopted.  It is noteworthy
that this alternative did not demonstrate kernel-residency for the C
instrumentation, thereby missing automagic maintenance benefits.


- FChE